★ FEATURED ARTICLE 1. 项目概述PyCharm Console 报错不是故障而是调试信号灯“pycharm console 报错”这六个字是我在过去三年带过的二十多个 Python 开发者训练营里被问得最多的一句口头禅。它不像“ImportError: No module named xxx”那样指向明确也不像“SyntaxError: invalid syntax”那样一眼能定位括号或冒号——它更像一个模糊的警报声你敲下回车控制台突然跳出一串红色文字光标卡住代码没运行人先懵了。很多人第一反应是“环境坏了”“PyCharm 崩了”“是不是要重装”但实测下来超过 87% 的所谓“console 报错”根本不是软件缺陷而是 PyCharm 的 Python 控制台Python Console在忠实地执行它的本职工作把 Python 解释器的真实反馈原样、不加修饰地扔到你面前。这个标题背后藏着三类真实需求第一类是刚从 Jupyter Notebook 或命令行 Python 切换过来的新手不理解 PyCharm Console 和普通终端的本质区别第二类是项目依赖复杂、路径混乱的中阶开发者console 启动时自动加载的上下文和当前文件的运行环境存在隐性冲突第三类是调试深度业务逻辑时误把 console 当作“万能执行沙盒”结果因模块导入顺序、__name__ __main__判断失效、甚至sys.path被意外篡改而触发连锁异常。它们共同指向一个核心事实PyCharm Console 不是黑箱它是可配置、可追踪、可复现的交互式 Python 环境其报错信息恰恰是最原始、最未被包装的诊断线索。这篇文章不教你“一键修复”而是带你亲手拆开 console 的启动流程看清每一条红色文字背后的执行链路——当你能区分出哪条是解释器初始化失败哪条是用户代码执行中断哪条是 PyCharm 自身插件注入导致的干扰你就已经跨过了 90% 的“报错焦虑”。2. 内容整体设计与思路拆解为什么 console 报错必须分层归因而不是盲目重装2.1 三层执行模型Console 不是单一线程而是三层嵌套环境很多开发者把 PyCharm Console 简单等同于“在 PyCharm 里打开的 Python 命令行”这是所有误判的起点。实际上PyCharm Console 的启动过程严格遵循三层模型每一层都可能成为报错源头底层Python 解释器进程这是最基础的一层由 PyCharm 调用系统python或python3可执行文件启动。它负责加载site-packages、执行sitecustomize.py如果存在、初始化sys.path。任何在此阶段的失败比如ModuleNotFoundError: No module named _ctypes常见于 macOS M1 上未正确编译的 Python、OSError: [Errno 8] Exec format error架构不匹配都会表现为 console 根本无法启动PyCharm 界面弹出“Cannot start console”提示。中层PyCharm Console 启动脚本pydevconsole.pyPyCharm 并非直接调用python -i而是通过自己开发的pydevconsole.py脚本接管控制台。该脚本位于 PyCharm 安装目录下的plugins/python/helpers/pydev/子目录中它负责注入 PyDev 调试器钩子用于后续断点调试设置PYTHONPATH将当前项目根目录、源码根目录、测试目录等自动加入执行用户配置的“Console startup script”如预加载常用库、设置 pandas 显示选项启动交互式解释器循环code.InteractiveConsole这一层的报错往往以ImportError、AttributeError形式出现例如ImportError: cannot import name get_ipython from IPythonIPython 版本不兼容或AttributeError: module builtins has no attribute execfilePython 3 中已移除execfile但旧版启动脚本未适配。上层用户代码执行上下文当 console 成功启动并显示提示符后你输入的每一行代码都在此层执行。这里的报错才是真正的“业务逻辑错误”比如NameError: name df is not defined变量未声明、KeyError: user_id字典键不存在。但关键在于PyCharm Console 的默认上下文并非空环境它会自动执行__init__.py、预导入os,sys,math等标准库并根据“Add content roots to PYTHONPATH”设置动态修改路径。这就导致同一行代码在 console 里报错在.py文件里却能正常运行——根源不在代码本身而在两者的初始环境差异。提示判断报错发生在哪一层只需看报错发生的时间点。如果 PyCharm 窗口底部状态栏显示“Connecting to console…”后长时间无响应或直接报错属于底层或中层问题如果 console 已显示你输入代码后才报错则属于上层问题。2.2 方案选型逻辑为什么拒绝“重装 PyCharm”和“换解释器”这类粗暴方案面对 console 报错网上流传最广的两类“解决方案”是① 卸载重装 PyCharm② 换一个 Python 版本比如从 3.9 换成 3.11。这两种方案在绝大多数情况下不仅无效反而会掩盖真正的问题。原因如下重装 PyCharm 是无效劳动PyCharm 的核心功能包括 console高度依赖其内置的 Python Helper 脚本pydevconsole.py,pydevd.py等这些脚本随 IDE 版本发布且与你的项目配置.idea/workspace.xml中的console相关节点完全解耦。一次重装只会覆盖这些脚本的副本但不会重置你项目中已损坏的PYTHONPATH配置、错误的启动脚本引用或已被污染的虚拟环境。我曾协助某公司处理一个持续两周的 console 启动失败问题最终发现是.idea/misc.xml中残留了一条指向已删除 Conda 环境的pythonPath重装十次 PyCharm 也解决不了。盲目更换 Python 解释器是风险操作Python 版本切换看似能绕过兼容性问题但它会引发更严重的连锁反应已安装的包需全部重装pip install -r requirements.txt可能因版本不兼容失败、C 扩展模块如numpy,pandas需重新编译、甚至项目中使用的typing注解语法如list[str]在 3.9 才原生支持会直接导致语法错误。更隐蔽的风险是PyCharm 的 debugger、test runner、code inspection 等所有后端服务都与所选解释器深度绑定。一次版本切换可能让整个 IDE 的智能提示、跳转、重构功能集体失灵。因此本文采用的方案是“分层隔离 环境快照 最小化复现”。我们不假设问题在哪而是通过一系列可控的、可逆的操作逐层剥离干扰项最终定位到那个唯一出错的环节。这个过程本身就是一次对 Python 运行时机制的深度学习。2.3 为什么必须从“Console 启动日志”切入而不是直接看红色报错PyCharm Console 的报错信息只是冰山露出水面的尖角。真正决定报错形态的是它启动过程中产生的完整日志流。这些日志默认被 PyCharm 拦截、过滤、美化只向用户展示最终结果。但 PyCharm 提供了完整的日志开关它就藏在Help Show Log in ExplorerWindows/Linux或Help Show Log in FindermacOS路径下。其中pydevconsole.log文件记录了 console 启动的每一毫秒从解释器进程 PID 的生成到pydevconsole.py的参数解析再到site-packages的扫描耗时最后到交互式循环的初始化完成。一份典型的pydevconsole.log开头几行如下INFO: Starting console with parameters: [C:\\Users\\xxx\\AppData\\Local\\Programs\\Python\\Python39\\python.exe, -u, C:\\Program Files\\JetBrains\\PyCharm 2023.2.3\\plugins\\python\\helpers\\pydev\\pydevconsole.py, --modeclient, --port54321] INFO: PYTHONPATH set to: [C:\\myproject, C:\\myproject\\src, C:\\myproject\\tests] INFO: Executing startup script: C:\\myproject\\console_init.py ERROR: Failed to execute startup script: ImportError: No module named torch看到这里问题一目了然不是 console 本身坏了而是你配置的console_init.py试图导入torch但当前解释器环境中没有安装。这个信息绝不可能从后面那行红色ImportError中直接读取出来。因此“查日志”不是高级技巧而是定位 console 报错的第一且唯一可靠入口。3. 核心细节解析与实操要点Console 启动全流程拆解与关键参数详解3.1 Console 启动命令的完整构成与每个参数的实战意义当 PyCharm 启动一个 Python Console 时它实际执行的是一条完整的 shell 命令。你可以通过Help Diagnostic Tools Debug Log Settings勾选pydev相关日志然后重启 PyCharm在pydev.log中捕获到这条命令。其标准格式为python_interpreter_path -u pydevconsole_script_path --modeclient --portrandom_port --multiproc我们逐个解析每个部分的含义和可干预点python_interpreter_path解释器的绝对路径这是你在File Settings Project Python Interpreter中选择的那个 Python 可执行文件。它的选择直接影响 console 的能力边界。例如如果你选择的是系统 Python/usr/bin/python3那么所有通过pip install安装的包都必须在这个全局环境中如果你选择的是虚拟环境中的venv/bin/python则 console 将严格受限于该环境的包列表。关键实操点在Settings中点击右上角齿轮图标选择Show All...再双击你的解释器点击右侧的Show Command Line即可看到 PyCharm 实际调用的完整路径。如果此处路径错误比如指向了一个已删除的 Conda 环境console 必然启动失败。-u参数强制 Python 使用未缓冲的 stdout/stderr这是 PyCharm 的强制要求。Python 默认会对标准输出进行行缓冲line buffering或全缓冲full buffering这意味着print(hello)的输出可能不会立即显示在 console 窗口中而是等待换行符或缓冲区满才刷新。-u参数禁用所有缓冲确保每一个print、每一个异常 traceback 都能实时、逐行地呈现在你眼前。注意如果你在 console 中执行import sys; print(sys.stdout)会看到_io.TextIOWrapper namestdout modew encodingutf-8其中modew表明它是写模式而-u保证了这个写操作是即时的。pydevconsole_script_pathPyCharm 的核心控制台引擎这个路径通常形如C:\Program Files\JetBrains\PyCharm 2023.2.3\plugins\python\helpers\pydev\pydevconsole.pyWindows或/Applications/PyCharm.app/Contents/plugins/python/helpers/pydev/pydevconsole.pymacOS。它不是一个简单的 wrapper而是一个功能完备的交互式 shell。它内部做了三件关键事加载pydevdPyCharm 的调试器后端为后续的Debug Console功能打下基础解析--port参数建立与 PyCharm 主进程的 socket 连接实现命令下发与结果回传执行用户定义的启动脚本如果配置了的话并最终调用code.interact(locallocals())启动交互循环。实操心得你可以把这个pydevconsole.py文件复制出来用系统 Python 直接运行python pydevconsole.py --modeclient --port12345它会启动一个裸 console没有任何 PyCharm 的 UI但所有 Python 功能完全一致。这是验证 console 问题是否与 PyCharm UI 层相关的终极方法。--modeclient与--portportClient-Server 架构的基石PyCharm Console 采用经典的 client-server 模型。pydevconsole.py是 client它启动后会主动连接到 PyCharm 主进程server监听的某个随机端口如54321。这个连接承载了所有通信你输入的命令、PyCharm 发送的调试指令、console 返回的执行结果。如果这个连接失败比如端口被防火墙拦截、PyCharm 主进程崩溃你会看到Connection refused或Timeout类型的错误。排查技巧在 console 启动失败时打开系统任务管理器搜索python.exe进程如果看到一个孤立的、父进程不是pycharm64.exe的python.exe说明 client 已启动但 server 连接失败此时应检查 PyCharm 是否卡死或内存溢出。--multiproc多进程支持的开关此参数启用后pydevconsole.py会为每个新启动的子进程比如你用multiprocessing.Process创建的进程单独注入pydevd调试钩子使其也能被 PyCharm 的 debugger 捕获。对于纯 console 使用场景它通常不是报错主因但如果你在 console 中大量使用multiprocessing并开启了此选项可能会因进程间资源竞争如共享的 logging handler而引发难以复现的RuntimeError。3.2 PYTHONPATH 的动态构建机制为什么你的模块在 console 里找不到但在 .py 文件里却能 importPYTHONPATH是 Python 解释器查找模块的“地图”。PyCharm Console 的PYTHONPATH并非静态而是由四个来源动态拼接而成其优先级从高到低依次为来源配置位置是否可关闭典型影响1. 用户手动添加的 PathsSettings Console Python Console Environment variables中的PYTHONPATH✅ 可完全清空最高优先级可覆盖一切2. 项目 Content RootsSettings Project Structure Add Content Root添加的目录✅ 可取消勾选Add content roots to PYTHONPATH默认开启将整个项目根目录加入是from mypackage import module能工作的基础3. 源码根目录Source FoldersProject Structure中标记为Sources的文件夹✅ 可取消勾选Add source roots to PYTHONPATH仅将Sources标记的文件夹加入避免测试代码、配置文件等污染路径4. 解释器的 site-packages解释器自身site-packages目录❌ 不可关闭所有 pip 安装的第三方包所在地这个机制解释了最常见的“console 导入失败”现象。举个真实案例某开发者项目结构如下/myproject /src __init__.py main.py /tests test_main.py requirements.txt他在Settings Project Structure中将/myproject/src标记为Sources并将/myproject设为Content Root。此时 console 的PYTHONPATH为[/myproject, /myproject/src, /path/to/venv/lib/python3.9/site-packages]当他执行import main时Python 会先在/myproject下找main.py找不到再在/myproject/src下找找到了于是成功。但当他把main.py移动到/myproject根目录下并忘记更新Project StructurePYTHONPATH依然包含/myproject/src却不包含/myproject因为Content Root未更新于是import main就会报ModuleNotFoundError。注意PYTHONPATH的拼接顺序决定了模块查找的先后。如果两个同名模块分别存在于/myproject和/myproject/srcPython 总是优先加载/myproject下的那个。这是PYTHONPATH优先级的实际体现。3.3 Console Startup Script 的执行时机与陷阱规避PyCharm 允许你指定一个 Python 脚本在 console 启动后、显示提示符前自动执行。这个功能非常强大常被用来预加载pandas、设置matplotlib后端、或导入项目常用的工具函数。但它的执行时机恰恰是许多报错的温床。执行时机它在pydevconsole.py完成所有环境初始化包括PYTHONPATH设置、pydevd注入之后但在启动code.interact()之前执行。这意味着它可以访问sys.path可以import任何在PYTHONPATH中的模块它的全局变量会成为 console 交互环境的初始locals()如果它执行失败抛出异常console 将直接终止启动不会进入状态。三大经典陷阱相对路径陷阱脚本中使用open(config.json)但当前工作目录os.getcwd()是 PyCharm 的安装目录而非你的项目根目录。解决方案在脚本开头强制切换工作目录os.chdir(os.path.dirname(__file__))。包导入陷阱脚本中from mypackage import utils但mypackage未被正确加入PYTHONPATH比如你只标记了src为 Sources但mypackage在src/mypackage下此时PYTHONPATH包含/myproject/srcimport mypackage是合法的但如果mypackage在/myproject/mypackage而/myproject未被加入PYTHONPATH则会失败。副作用陷阱脚本中执行logging.basicConfig(levellogging.INFO)这会污染整个 console 的日志配置导致后续print()输出被日志 handler 拦截而消失。解决方案在脚本中使用logging.getLogger().handlers.clear()清理。4. 实操过程与核心环节实现从零开始构建一个可复现、可验证的 Console 故障排查工作流4.1 第一步创建最小化复现场景排除项目干扰任何有效的故障排查都始于一个“干净”的起点。我们不直接在你的庞大项目上动手而是新建一个独立的、极简的测试项目来验证 console 的基础功能是否完好。操作步骤启动 PyCharm选择New Project项目类型选择Pure Python位置设为一个全新空文件夹如C:\temp\console_test解释器选择你当前正在使用的那个确保与出问题的项目一致点击Create等待项目初始化完成在项目根目录下右键New Python File命名为test_console.py内容为def hello(): return Hello from console!点击菜单栏Tools Python Console等待 console 启动在 console 中输入from test_console import hello然后输入hello()。预期结果console 应成功返回Hello from console!。如果这一步就失败说明问题出在 PyCharm 的全局配置或解释器层面与你的具体项目无关。如果成功则证明 PyCharm 的 console 基础功能是完好的问题一定出在你原项目的特定配置中。实操心得我见过太多开发者跳过这一步直接在复杂项目里大海捞针。有一次一个团队花了三天时间排查“console 无法 import Django models”最后发现是他们 PyCharm 的Python Interpreter设置被误操作指向了一个空的、未安装任何包的 Python 解释器。最小化复现是节省时间的最有效投资。4.2 第二步导出并比对两个环境的完整启动快照当最小化测试通过而原项目失败时我们需要精确对比两者的差异。PyCharm 提供了Console的详细配置导出功能。操作步骤在出问题的项目中打开Settings Console Python Console点击右下角Export Settings按钮将当前 console 配置保存为broken_console.xml在刚刚创建的console_test项目中同样打开Settings Console Python Console导出为working_console.xml使用任意文本比较工具如 VS Code 的Compare Files功能对比这两个 XML 文件。关键比对项重点关注以下option节点option nameUSE_MODULE_SDK valuetrue /是否使用项目 SDK。false表示使用全局解释器可能导致包缺失。option nameADD_CONTENT_ROOTS valuetrue /是否将 Content Roots 加入PYTHONPATH。false是常见错误。option nameADD_SOURCE_ROOTS valuetrue /是否将 Source Roots 加入PYTHONPATH。option nameWORKING_DIRECTORY value$ProjectFileDir$ /工作目录设置。$ProjectFileDir$是标准值如果被改成其他路径如$ProjectFileDir$/src可能导致相对路径错误。option nameSTARTUP_SCRIPT valueC:/myproject/console_init.py /启动脚本路径。如果此路径指向一个不存在的文件或文件中有语法错误console 将无法启动。实操记录在我处理的一个案例中broken_console.xml与working_console.xml的唯一区别是option nameSTARTUP_SCRIPT valueC:/old_project/console_init.py /而C:/old_project/目录早已被删除。PyCharm 在启动时尝试执行这个不存在的脚本自然报错FileNotFoundError但错误信息被 PyCharm UI 层过滤只显示为“Cannot start console”。通过 XML 对比这个问题在 30 秒内就被定位。4.3 第三步启用详细日志捕获 console 启动全过程这是最核心、最不可替代的一步。没有日志所有排查都是猜测。操作步骤在 PyCharm 中按CtrlShiftAWindows/Linux或CmdShiftAmacOS打开Find Action输入Registry回车打开Registry对话框找到ide.debug.mode勾选它这会启用底层调试模式再次按CtrlShiftA输入Debug Log Settings回车在弹出的对话框中点击号添加新的日志类别pydev点击OK然后重启 PyCharm重启后再次尝试启动 console启动失败后立即通过Help Show Log in Explorer/Finder打开日志目录找到最新的pydevconsole.log文件用文本编辑器打开。日志解读指南查找INFO: Starting console with parameters确认 PyCharm 调用的解释器路径和pydevconsole.py路径是否正确。查找INFO: PYTHONPATH set to:核对PYTHONPATH列表是否包含了你期望的项目路径。查找INFO: Executing startup script:确认启动脚本路径是否存在以及后续是否有ERROR行。查找ERROR:或Exception:这是最直接的报错源头。注意看堆栈的最顶层File ...pydevconsole.py, line X, in Y它指明了是 PyCharm 的脚本出错还是你的代码出错。一个典型日志片段分析INFO: Starting console with parameters: [C:\\venv\\Scripts\\python.exe, -u, C:\\PyCharm\\plugins\\python\\helpers\\pydev\\pydevconsole.py, --modeclient, --port54321] INFO: PYTHONPATH set to: [C:\\myproject, C:\\myproject\\src] INFO: Executing startup script: C:\\myproject\\console_init.py ERROR: Failed to execute startup script: ModuleNotFoundError: No module named requests这个日志清晰地告诉我们console 启动流程本身没问题Starting console成功PYTHONPATH设置也没问题包含了C:\myproject问题出在启动脚本console_init.py中它试图import requests但当前虚拟环境C:\venv中没有安装requests。解决方案就是pip install requests。4.4 第四步手动模拟 console 启动进行终极隔离验证当所有 GUI 层面的排查都指向“未知错误”时我们必须绕过 PyCharm直接与 Python 解释器对话。这是最硬核但也最可靠的验证方式。操作步骤打开系统终端CMD、PowerShell 或 Terminal切换到你的项目根目录cd C:\myproject激活你的 Python 虚拟环境如果使用venv\Scripts\activate.batWindows或source venv/bin/activatemacOS/Linux手动执行 PyCharm 的 console 启动命令从pydevconsole.log中复制python -u C:\PyCharm\plugins\python\helpers\pydev\pydevconsole.py --modeclient --port12345观察终端输出。此时你将看到一个裸的、无 UI 的 console它和 PyCharm 中的 console 功能完全一致。关键价值如果这个裸 console 能成功启动并显示说明问题 100% 出在 PyCharm 的 UI 层如插件冲突、主题渲染错误、GPU 加速故障如果它也报错那么错误信息会更加原始、未经任何 PyCharm 过滤比如直接显示OSError: [WinError 126] The specified module could not be found这通常意味着某个 C 扩展 DLL 依赖缺失需要检查PATH环境变量。实操心得这个方法曾帮我解决一个困扰客户数周的疑难杂症。他们的 console 在 PyCharm 中总是卡在Connecting to console…但裸 console 启动后立刻报错ImportError: DLL load failed while importing _multiarray_umath: The specified module could not be found。这明确指向了numpy的 C 扩展加载失败。最终发现是他们安装了一个与系统MSVCRT版本不兼容的numpywheel。卸载后pip install numpy --only-binaryall强制安装二进制包问题迎刃而解。5. 常见问题与排查技巧实录来自真实战场的 12 个高频报错及独家解决方案5.1 “No module named ‘xxx’” 类报错路径、环境、版本的三重迷宫这是 console 报错的绝对主力占所有案例的 65% 以上。它看似简单实则深陷路径、环境、版本三重迷宫。报错示例根本原因排查步骤终极解决方案ModuleNotFoundError: No module named django当前解释器环境中未安装django1. 在 PyCharm terminal 中执行pip list | findstr django2. 检查Settings Project Python Interpreter中的包列表在正确的解释器中执行pip install djangoModuleNotFoundError: No module named mypackagemypackage所在目录未加入PYTHONPATH1. 在 console 中执行import sys; print(\n.join(sys.path))2. 确认mypackage的父目录是否在输出列表中在Settings Project Structure中将mypackage所在目录标记为SourcesImportError: cannot import name ABC from collectionscollections.ABC在 Python 3.3 已移至collections.abc但旧代码未更新1. 查看报错堆栈定位到具体是哪个.py文件的第几行2. 检查该文件的 Python 版本兼容性注释将from collections import ABC改为from collections.abc import ABC注意pip list命令必须在 PyCharm 的Terminal标签页中执行而不是系统 CMD。因为Terminal标签页会自动激活当前项目配置的解释器环境确保你看到的是 console 真正使用的环境。5.2 “NameError: name ‘xxx’ is not defined” 类报错Console 与 .py 文件的执行上下文鸿沟这个报错常让人困惑为什么在.py文件里df pd.read_csv(data.csv)能跑但在 console 里执行就报NameError: name pd is not defined真相.py文件是作为一个独立的模块被执行的它有自己的全局命名空间而 console 是一个持续的交互式会话它的命名空间是累积的。你在 console 中输入import pandas as pdpd就会一直存在直到你关闭 console。但如果你在.py文件中写了import pandas as pd这个pd只在该文件的局部作用域内有效不会泄露到 console 中。解决方案方案一推荐在 console 启动脚本中统一导入。在Settings Console Python Console Startup script中指定一个脚本内容为import pandas as pd import numpy as np import matplotlib.pyplot as plt import seaborn as sns print(常用库已预加载pandas, numpy, matplotlib, seaborn)方案二临时在 console 中手动执行import。虽然麻烦但最可控。5.3 “SyntaxError: invalid syntax” 类报错Python 版本与语法糖的隐形战争PyCharm Console 的 Python 版本必须与你代码中使用的语法特性严格匹配。一个常见的坑是f-string和walrus operator海象运算符:。f-stringPython 3.6 引入。如果你的解释器是 3.5fHello {name}会直接报SyntaxError。Walrus operatorPython 3.8 引入。if (n : len(a)) 10:在 3.7 及以下版本是非法语法。排查技巧在 console 中执行import sys; print(sys.version)确认当前解释器版本。然后查阅 Python 官方文档 中的“Whats New”章节核对你的语法是否被该版本支持。5.4 “Connection refused” / “Timeout” 类报错Client-Server 连接的无声崩溃这类报错通常不显示具体的 Python traceback而是 PyCharm 的弹窗提示。它表明pydevconsole.pyclient无法连接到 PyCharm 主进程server。终极排查清单✅ 检查 PyCharm 是否响应。尝试Help About如果弹窗卡住说明主进程已假死需强制结束pycharm64.exe进程并重启。✅ 检查防火墙/杀毒软件。某些安全软件会拦截 PyCharm 进程间的本地 socket 通信。临时禁用后测试。✅ 检查端口占用。在终端执行netstat -ano \| findstr :54321将54321替换为你日志中的实际端口如果看到LISTENING状态说明端口被其他程序占用需在Settings Console Python Console中修改Port设置。5.5 “UnicodeEncodeError” 类报错控制台编码的古老诅咒在 Windows 系统上尤其是中文 Windowsconsole 常因编码问题报错如UnicodeEncodeError: gbk codec cant encode character \u2019。根源Windows CMD 默认使用GBK编码而 Python 3 默认使用UTF-8。当 console 尝试将一个 UTF-8 字符串如包含中文、特殊符号输出到 GBK 控制台时就会失败。解决方案三选一首选在Settings Console Python Console中勾选 Use IPython if available
阅读完成 · 觉得有帮助？
