Sublime Text4 配置 Python 运行环境：构建系统与插件实战

1. 为什么我最后还是回到 Sublime Text4 搭 Python 环境

Sublime Text4 搭 Python 运行环境这件事，我从 Sublime Text3 时代一直折腾到现在，中间来来回回换过 PyCharm、VS Code，甚至尝试过在终端里纯靠 vim 加插件硬扛，最后还是回到了 Sublime Text4。原因说出来可能有点反直觉：不是因为它功能最全，恰恰是因为它功能最少、最不打扰我。Python 这门语言本身对编辑器的要求其实很低，写脚本、跑数据处理、调一段爬虫逻辑，真正吃性能的是解释器和第三方库，编辑器只要做到启动快、按键响应跟手、能一键把当前文件丢给解释器执行就算合格。

很多人刚开始学 Python 的时候会陷入一个误区，觉得非得装一个"专业的 Python IDE"才能开始写代码。结果装完之后被索引、被虚拟环境识别、被各种弹窗和各种自动补全拖得头大，写了三行 print 就开始怀疑人生。而用 Sublime Text4 搭建 Python 运行环境的核心价值就在这儿：它把一个纯粹的文本编辑器和系统里的 Python 解释器用一条命令连起来，剩下的交互逻辑全部交给你自己掌控。你要补全就装补全插件，要断点就装断点插件，要终端就装终端插件，一层一层往上叠，出问题的时候你清楚是哪一层出的问题。

这篇文章面向的是已经装好 Python、准备找一个轻量编辑器开始写代码的人，也面向那些用了 IDE 觉得太重、想换回轻量方案的老手。我会把从零开始的完整路径讲一遍，包括解释器怎么选、构建系统怎么写、插件怎么搭、踩过的坑怎么绕，尽量让第一次接触 Sublime Text4 的人也能照着做出来，而不是只给一串看不懂的配置文件就完事。

说白了，Sublime Text4 运行 Python 的本质就是三个东西对齐：编辑器里当前打开的文件路径、系统里 Python 解释器的绝对路径、以及两者之间的调用方式。这三个东西任意一个错位，就会出现"按了 Ctrl+B 没反应""报 command not found""输出了一堆乱码"这类问题。后面的章节我会把它们拆开逐个讲清楚。

2. 环境准备：Python 解释器与 Sublime Text4 的正确装法

2.1 Python 安装时那几个必须留意的选项

Python 官方安装器在 Windows 上有个著名的复选框叫 Add Python to PATH，默认是不勾的。我见过太多人装完之后在 Sublime 里跑代码报'python' 不是内部或外部命令，回头一看就是这里没勾。如果你已经装完了又不想重装，可以手动把 Python 安装目录和它的 Scripts 子目录加到系统环境变量里，但更省事的办法是卸载重装一次，勾上那个框，两分钟的事。另外安装器的第一屏有个 Install Now 和 Customize installation，我一般选 Customize，把 pip、tcl/tk、py launcher 这几个都留着，尤其是 py launcher，后面在 Sublime 里调用多版本解释器会非常方便。

macOS 用户需要注意的是系统自带的/usr/bin/python3其实是命令行工具链附带的，能用但不建议拿来装第三方库，装到系统目录里容易出现权限问题。我一般用 Homebrew 装一份，路径在 Apple 芯片机器上是/opt/homebrew/bin/python3，Intel 机器上是/usr/local/bin/python3。Linux 发行版大多自带 python3，用which python3确认一下位置就行，缺 pip 的话用python3 -m ensurepip补上。

至于具体装哪个版本，我的建议是 3.10 到 3.12 之间挑一个，太新的版本有些第三方库的轮子还没跟上，编译安装会极其痛苦，尤其是涉及科学计算的那几个包。至于 2.7 就别考虑了，连官方都停止维护了。

装完之后别急着打开 Sublime，先在终端里执行三条命令验证一下：python --version或者python3 --version看版本号，where python（Windows）或which python3（macOS/Linux）看解释器路径，python -c "print('ok')"看能不能正常执行并输出。这三条都过了，说明解释器这一层没问题，接下来才是编辑器的事。

注意：把解释器的绝对路径记下来，后面写构建系统会直接用到。路径里如果带空格（比如用户目录叫C:\Program Files\...），在配置文件里的写法要格外小心，后面会讲怎么处理。

2.2 Sublime Text4 安装与初始配置

Sublime Text4 的安装没什么可说的，官网下载对应平台的安装包，一路下一步就行。装完第一次打开，我一般先做四件事，都是提升后续体验的基础设置。

第一件是把 Packages 目录的位置搞清楚。Windows 在%APPDATA%\Sublime Text\Packages\User\，macOS 在~/Library/Application Support/Sublime Text/Packages/User/，Linux 在~/.config/sublime-text/Packages/User/。这个目录是你所有自定义配置文件的落脚点，构建系统、快捷键、插件设置都存这儿。注意 ST4 的目录名是Sublime Text，不是 ST3 的Sublime Text 3，从旧版本迁移配置的时候别搞混了。

第二件是在设置里打开几个关键项。用 Ctrl+Shift+P 调出命令面板，输入 Preferences: Settings 回车，在右侧的用户设置文件里加几条：

{ "translate_tabs_to_spaces": true, "tab_size": 4, "draw_white_space": "all", "trim_trailing_white_space_on_save": true, "ensure_newline_at_eof_on_save": true, "word_wrap": false, "show_encoding": true, "highlight_line": true }

Python 官方风格指南要求用四个空格缩进，所以translate_tabs_to_spaces和tab_size是必设的，不然混用 Tab 和空格会直接把IndentationError请出来，而且这种错误最难找，肉眼完全看不出区别。trim_trailing_white_space_on_save是保存时自动删掉行尾空格，看着舒服，也能避免某些场景下的提交噪音。show_encoding会在状态栏显示当前文件的编码，处理中文文本的时候能第一时间发现问题。

第三件是装 Package Control。ST4 内置了通过命令面板安装 Package Control 的入口，按 Ctrl+Shift+P 输入 Install Package Control 回车，等几秒就好了。后面所有插件都靠它管理，这一步必须做。

第四件是把文件的默认语法关联确认一下。打开一个.py文件，看右下角是不是显示 Python。如果不是，点右下角选 Python，ST4 会自动记住这个关联关系。语法关联影响的不只是高亮，还影响构建系统的 selector 匹配，如果语法没识别成 Python，按 Ctrl+B 可能会用错构建系统。

3. 三种运行方案对比：从最简到最顺手

3.1 方案一：用构建系统直连解释器

这是最轻、最没有依赖的方案，也是我日常写脚本时的默认选择。原理很简单：Sublime 把当前文件路径拼成一条命令，交给系统 shell 去执行，然后把标准输出和标准错误抓回来显示在底部面板里。整个过程不依赖任何插件，装完 Sublime 开箱就能用。

新建构建系统的方法是点菜单 Tools > Build System > New Build System，会打开一个带模板的空白文件，把内容换成下面这样：

{ "shell_cmd": "python -u \"$file\"", "file_regex": "^[ ]*File \"(...*?)\", line ([0-9]*)", "selector": "source.python", "encoding": "utf-8", "working_dir": "$file_path", "env": { "PYTHONIOENCODING": "utf-8" } }

然后 Ctrl+S 保存，文件名起成Python3.sublime-build，Sublime 会自动存到 User 目录下。保存完切回你的 .py 文件，Ctrl+Shift+B 选择 Python3 这个构建系统，之后按 Ctrl+B 就能跑代码了。

这里每一个字段都有它的用处，值得逐条说清楚。shell_cmd是真正执行的命令，$file是 Sublime 的变量，会被替换成当前文件的完整路径，外层加引号是为了应付路径里有空格的情况。-u参数是关闭 Python 的输出缓冲，这个参数不加的话，程序运行过程中 print 的内容会攒在缓冲区里，直到程序结束才一次性吐出来，写循环或者长时间运行的任务时会让人以为程序卡死了。file_regex是用来解析错误信息的正则，Python 抛出异常时的格式是File "xxx.py", line 12这种，正则在尾部面板里把这些位置识别成可点击的链接，双击就能跳到出错行，这个功能用惯了之后就回不去了。

selector字段限定这个构建系统只在 Python 语法的文件里生效，避免你打开一个 JS 文件按 Ctrl+B 结果跑了 Python 解释器这种乌龙。working_dir设成文件所在目录很关键，尤其当你代码里有相对路径读写文件的时候，不设这个的话工作目录会是 Sublime 的安装目录或者上次的目录，open('data.csv')必然找不到文件。env里设PYTHONIOENCODING是专门对付中文输出乱码的，这个后面还有一节专门讲。

这套方案的优势是干净、快、无依赖，缺点是没法交互输入。一旦代码里出现input()，程序就会挂在那儿等输入，而 Sublime 的输出面板是只读的，你敲什么都没用。这是它的硬伤，也是很多人弃用的原因。

3.2 方案二：Terminus 插件做交互式终端

想要在 Sublime 里面跑能输入的程序，Terminus 是目前最靠谱的选择。它本质上是把系统终端嵌进 Sublime 的一个面板里，支持完整的交互，input()、getpass、sys.stdin.readline()全都能正常工作。

安装方式是 Ctrl+Shift+P 输入 Package Control: Install Package，然后搜 Terminus 回车。装完之后你的命令面板里会多出一批Terminus: ...开头的命令，最常用的是Terminus: Open Default Shell in Panel，绑个快捷键就能随时呼出一个终端面板。

真正把 Terminus 和 Python 运行结合起来的做法，是给它单独写一个构建系统。在 User 目录新建Python3_Terminus.sublime-build：

{ "target": "terminus_open", "cmd": ["python", "-u", "$file"], "cwd": "$file_path", "selector": "source.python", "title": "Python Run", "auto_close": false, "panel": { "rows": 12 } }

关键的字段是target，它告诉 Sublime 不要用默认的执行器，而是调用 Terminus 提供的terminus_open命令。cmd写成数组形式，Sublime 会自己处理路径中的引号，比拼字符串更稳。cwd就是工作目录，效果等同于前面说的working_dir。auto_close设成 false，意思是程序跑完后终端面板不关，这样你能回看输出，调试的时候特别有用。如果你嫌它一直挂着，改成 true 也行。

panel里的rows控制终端面板的高度，12 行大概占了屏幕下面三分之一，跑一些输出量大的脚本比较合适。这个值你可以根据自己屏幕大小调整。

用 Terminus 跑构建有个小细节要注意：它每次执行会开一个新的终端面板，如果你反复按 Ctrl+B，面板会越开越多。习惯做法是跑之前先按 Ctrl+Shift+P 执行Terminus: Close All Terminals清一下，或者干脆用命令面板里的Terminus: Kill All Terminals。我自己是把它绑到 Ctrl+Alt+K 上，跑新的之前先按一下，眼不见心不烦。

另外还有一个容易被忽略的点：Terminus 在 Windows 上默认调用的是 PowerShell，在 macOS 和 Linux 上调用的是系统默认 shell。如果你希望它用 cmd 而不是 PowerShell，可以配合 Terminal 插件的设置，或者在配置里显式指定shell_cmd。这个差异主要影响你对命令语法的熟悉度，对 Python 执行本身没什么影响。

3.3 方案三：SublimeREPL 与 Anaconda 插件的取舍

SublimeREPL 是 ST2 时代就存在的老牌插件，能给 Sublime 嵌一个真正的 Python 交互式解释器，可以一行一行敲代码执行，像在终端里开 python 那样。它在 ST4 上仍然能装能用，但说实话已经很久没更新了，遇到 ST4 的一些新特性会有点水土不服，比如某些快捷键在较新版本上会被抢占。如果你只是想解决input()的问题，Terminus 比它更值得选；如果你特别想要一个能逐行执行、保留变量的 REPL 会话，那 SublimeREPL 还是值得试一下的。

Anaconda 这个插件名字容易和 Python 发行版 Anaconda 混淆，但它其实是 Sublime 上一个纯 Python 开发辅助插件，跟那个发行版没关系。它基于 Jedi 提供补全、跳转定义、查看文档、lint 检查、自动格式化等一整套功能，相当于在轻量编辑器里塞了半个 IDE 的体验，安装后需要手动在设置里指定python_interpreter的路径，否则它内部的解析器可能识别不到你装的第三方库，补全就会残缺不全。

我自己的取舍是这样的：日常写脚本用方案一，需要输入交互或者调试输出量大的程序用方案二，方案三只在需要认真做一个中型项目、补全和跳转需求明显上升的时候才启用。三种方案不是互斥的，你完全可以在同一个 Sublime 里配好几个构建系统，用 Ctrl+Shift+B 现场切换，根据手头代码的性质决定用哪个跑。

4. 构建系统核心参数逐条拆解与多环境处理

4.1 .sublime-build 文件里每个字段的作用

构建系统这个配置文件看着简单，但每个字段踩过的坑都不少。我用一个表格把常用字段和它们的作用、以及配置错误时的典型症状整理出来，对照着排查会快很多。

关于cmd和shell_cmd的优先级，值得单独说一下。Sublime 在处理的时候如果两个都写了，cmd会被忽略，只认shell_cmd。这个行为在官方文档里提到过但不是特别显眼，我自己就曾经两个都写，结果改了cmd发现没生效，纠结了半天。

variants的用法也很实用，一个构建文件里可以定义多个变体，让 Ctrl+Shift+B 弹出列表供你选。比如同时配一个正常运行的变体和一个带-i交互模式的变体：

{ "shell_cmd": "python -u \"$file\"", "file_regex": "^[ ]*File \"(...*?)\", line ([0-9]*)", "selector": "source.python", "working_dir": "$file_path", "variants": [ { "name": "Run in Terminal", "target": "terminus_open", "cmd": ["python", "-u", "$file"] }, { "name": "Compile Check", "shell_cmd": "python -m py_compile \"$file\"" } ] }

第一个变体直接借用了 Terminus 的能力，第二个变体只做语法编译检查，不执行代码，写大脚本之前先跑一遍能避免很多愚蠢的错误。这种组合在实际工作里的作用比想象中大，尤其是接手别人的代码或者做重构的时候。

4.2 编码、多版本、虚拟环境三个高频场景

先说编码。中文乱码这个问题的根源在于 Windows 上 Python 默认用系统本地编码（通常是 GBK 或者说 cp936）来输出到控制台，而 Sublime 的输出面板默认按 UTF-8 解码，两边对不上就会出乱码。解决办法有两层：一是在构建系统里通过env设PYTHONIOENCODING=utf-8，强制 Python 用 UTF-8 输出；二是在encoding字段里声明输出面板的解码方式。这两层配好之后，绝大多数中文乱码就消失了。

如果还是乱码，检查一下你的 Python 版本。3.7 之后PYTHONIOENCODING的优先级比较高，3.6 及以前有时候会被PYTHONUTF8之类的设置覆盖。实在搞不定的时候，有个土办法是在代码开头加两行重设标准输出：

import sys import io sys.stdout = io.TextIOWrapper(sys.stdout.buffer, encoding='utf-8')

这招不优雅但有效，我在处理一些遗留环境的时候用过。

再说多版本。很多人的机器上同时装了 Python3.8 和 3.11，或者既有官方版又有发行版，这时候shell_cmd里直接写python调用的是 PATH 里第一个，不一定是你想要的那个。解决办法是把绝对路径写死，比如C:\\Users\\me\\AppData\\Local\\Programs\\Python\\Python311\\python.exe，注意 JSON 里的反斜杠要写两个。更规范的做法是给每个版本各写一个构建文件，用 Ctrl+Shift+B 切换。Windows 上还可以用 py launcher：py -3.11 -u "$file"这种方式指定版本，比写绝对路径干净，前提是装 Python 的时候选了 py launcher。

虚拟环境是另一个必须处理的场景。用 venv 创建的虚拟环境，解释器在.venv\Scripts\python.exe（Windows）或.venv/bin/python（macOS/Linux），不写全路径的话跑的还是系统全局解释器，那你装进虚拟环境的库一个都 import 不到。我习惯给虚拟环境单独写一个构建系统，把解释器路径写死成相对项目根目录的形式，反正项目就那几个，切换成本不高。

至于用发行版自带的 conda 环境，解释器路径一般在开头目录/envs/环境名/bin/python或者 Windows 下的Scripts\python.exe。用conda info --envs能列出所有环境的路径，照抄就行。

提示：写绝对路径的时候，如果路径里包含中文或者空格，务必在shell_cmd里用引号包住。JSON 字符串里的双引号要转义成\"，这是很多人第一次写构建系统时最容易漏的地方。

5. 插件搭配：把补全、跳转、格式化补齐

5.1 LSP 系插件与传统补全插件的路线差异

Sublime Text4 原生的 Python 补全非常弱，基本只靠当前文件里的词法匹配，跨文件、跨库的跳转几乎没戏。要把它变成能用的开发环境，补全这一块必须靠插件。目前主流是两条路线：一条是以 LSP 为基础的现代路线，另一条是以 Jedi 为核心的传统路线。

LSP 路线的做法是先装 LSP 这个基础包，它实现了编辑器与语言服务器之间的通用通信协议，然后针对 Python 再装 LSP-pyright 或者 LSP-pylsp。Pyright 本质上是把 VS Code 里那套 Python 类型推断引擎搬了过来，补全准确度高，类型检查严格，对大型项目的支持明显更好。缺点是首次打开项目要跑索引，内存占用比传统方案高一点，机器配置一般的话会有短暂的卡顿感。

传统路线就是前面提到的 Anaconda 插件，它直接调 Jedi 做补全，轻量、启动快、资源占用低。对于写脚本、做小工具、跑数据分析这类场景完全够用。它的短板在于复杂项目的类型推断准确率不如 Pyright，尤其是涉及动态类型和装饰器的时候经常猜不准。

我自己的搭配是：日常写脚本用 Anaconda，开中型项目用 LSP-pyright，两者都装但不同时对一个文件启用，避免补全列表里出现重复项干扰选择。切换的方式是在项目文件里设 project-specific settings，或者直接用命令面板禁用其中一个。

无论用哪条路线，安装完后都必须做一件事：指定解释器路径。LSP-pyright 需要在 LSP 的设置里配python.pythonPath，Anaconda 需要在它的设置里配python_interpreter。不指定的话，它用的是插件自己找的解释器，往往跟你实际用的不是同一个，表现就是明明 pip 装了某个库，补全里却没有，白折腾半天。

5.2 格式化、静态检查与快捷键绑定

补全之外，还有几个小工具能让写 Python 的体验明显变好。

格式化我推荐用sublime-rustfmt这类通用格式化框架配合 black 来做，或者直接用Python Black这个插件，它把 black 包装成了 Sublime 命令，选中代码按快捷键就能格式化。black 的好处是基本没有配置项，省去了争论缩进和换行的功夫，团队协作时也少了很多风格拉扯。

静态检查可以把 flake8 或 ruff 接进来，通过 SublimeLinter 这个框架管理。SublimeLinter 本身不做检查，它只是一个调度器，你装SublimeLinter-flake8这样的配套包，它就会在你敲代码的时候把问题直接标在行号旁边，鼠标移到波浪线上能看到具体信息。这个交互比等到运行时报错再回来找要高效得多，尤其是未使用变量、未定义名称这类问题，写的时候就能发现。

快捷键是最后一块拼图。常用的几个操作我建议都绑上，减少鼠标和命令面板的来回切换：

• Ctrl+B用默认构建系统运行当前文件，这个建议保留原生行为
• Ctrl+Shift+B在多个构建变体间选择，原生行为也用得上
• F5我绑给了 Terminus 打开默认 shell，随手开个终端
• Ctrl+Alt+K绑给关闭所有 Terminus 面板
• Ctrl+Alt+F绑给 black 格式化

快捷键的配置文件在 User 目录下的Default (Windows).sublime-keymap（macOS 是Default (OSX).sublime-keymap），格式是 JSON 数组，每条包含keys和command两个字段。注意command的名字必须和插件注册的命令完全一致，差一个字母就静默失效，调试的时候可以用 Ctrl+` 打开控制台看 Sublime 的日志输出。

有一点要提醒：Sublime 的键位冲突检测很不友好，如果你绑的键被别的插件或者系统占用了，它不会提示，就是没反应。遇到这种情况，用一个很冷门的组合键先试，确认命令本身是通的，再慢慢往常用的键位上挪。

6. 踩坑记录与常见问题速查表

6.1 运行无输出与报错定位

按了 Ctrl+B 什么都没发生，是最常见的第一道坎。排查顺序我一般是这样走的：先看右下角语法是不是 Python，再看状态栏显示的构建系统名字对不对，接着用命令面板执行Build With: ...手动选一次，最后才去看配置文件。绝大多数时候问题出在前两步——文件被识别成了 Plain Text，或者上一次手动选过别的构建系统而 Sublime 记住了这个选择。Sublime 的构建系统选择是按文件语法记忆的，换了语法就要重新选一次。

如果命令确实执行了但输出面板是空的，先确认代码里有没有 print，再确认是不是加了-u参数。有一种情况是程序抛了异常但异常信息被吞了，这种多半是因为构建系统的target被改成了不捕获输出的执行器。恢复成默认行为的方法是删掉target字段，让它走内置的 exec 执行器。

报No such file or directory或者can't open file这类错误，八成是$file变量没被正确替换，或者是路径里有空格而引号没加对。这时候可以把shell_cmd改成echo "$file"先跑一次，看看实际拼出来的命令长什么样，比盯着配置猜要快得多。

IndentationError和TabError看着吓人，本质上都是缩进字符不统一。解决办法就是前面提到的设置里打开translate_tabs_to_spaces，然后对已经在用的文件执行一次全量转换。Sublime 里可以用 Ctrl+A 全选，然后 View > Indentation > Convert Indentation to Spaces 一次性搞定。

6.2 编码、输入、虚拟环境相关的坑

input()卡死这个问题，前面已经说了，方案就是换 Terminus。这里补充一个细节：用 Terminus 跑的时候，如果你在终端面板里粘贴内容，可能会触发终端的括号粘贴模式，导致粘贴的内容被当成一大串控制字符。遇到这种情况，检查一下 Terminus 的设置里有没有启用 bracketed paste，关掉就好。

中文路径是另一个容易翻车的点。Windows 上的用户名如果带中文，Python 解释器的路径里就会有中文，写进构建系统后在某些编码设置下会解析失败。稳妥的做法是把 Python 装到一个纯英文路径下，或者用 py launcher 来调用，绕开路径拼写的问题。

虚拟环境识别这块，有个特别隐蔽的坑：你激活了虚拟环境，在终端里python -V显示的是虚拟环境版本，但在 Sublime 里按 Ctrl+B 跑出来的还是全局解释器。原因就是 Sublime 启动时继承的是系统环境变量，不会因为你后来在某个终端里激活了虚拟环境而跟着变。唯一的解法就是在构建系统里写死虚拟环境解释器的绝对路径，别指望 Sublime 能感知到你终端里的激活状态。

还有一个和缓存有关的小坑。用py_compile或者导入模块的时候，Python 会生成__pycache__目录。如果你在 Sublime 的侧边栏里看到一堆这种目录，可以在设置里把它们隐藏掉：在用户设置的folder_exclude_patterns里加上__pycache__，界面会清爽很多。

下面这张表是我自己整理的速查表，遇到问题先对号入座，比从头排查快。

7. 我日常在用的完整配置清单

把上面这些东西拼起来，我日常的 Sublime Text4 Python 环境大概是这样一套配置，直接抄作业也能跑起来。

构建系统放两个文件。Python3.sublime-build负责常规执行，用内置 exec 执行器，输出走底部面板，速度快、不打扰：

{ "shell_cmd": "python -u \"$file\"", "file_regex": "^[ ]*File \"(...*?)\", line ([0-9]*)", "selector": "source.python", "encoding": "utf-8", "working_dir": "$file_path", "env": { "PYTHONIOENCODING": "utf-8" }, "variants": [ { "name": "Syntax Check", "shell_cmd": "python -m py_compile \"$file\"" } ] }

Python3_Terminus.sublime-build负责需要交互的场景，行数设成 14，跑完不自动关：

{ "target": "terminus_open", "cmd": ["python", "-u", "$file"], "cwd": "$file_path", "selector": "source.python", "title": "Python", "auto_close": false, "panel": { "rows": 14 } }

插件方面，必装的是 Package Control、Terminus、SublimeLinter 加 SublimeLinter-flake8、Python Black，补全插件按项目规模在 Anaconda 和 LSP-pyright 里二选一。快捷键绑三个：F5 开终端，Ctrl+Alt+K 关所有终端，Ctrl+Alt+F 格式化。

这套配置下来，打开一个 .py 文件到跑出结果，整个过程不超过两秒，内存占用也就一百多兆，跟那些动辄吞掉一两个 G 的 IDE 完全不是一个量级。你要说它缺什么，缺的是图形化调试器、缺的是开箱即用的单元测试面板、缺的是数据库工具窗口。但这些东西对写脚本和做数据处理的人来说，一个月用不上一次，为了它们牺牲日常的响应速度，我觉得不划算。

真到了需要断点调试的时候，我也不是硬扛，直接把文件丢到终端里用python -m pdb跑，或者临时开一下别的工具，任务做完就切回来。工具是为任务服务的，反过来被工具绑架就没意思了。

最后再提一个我自己用了很久的小技巧：把$file_path里的项目根目录记在一个 note 里，切换项目的时候直接把构建系统里的working_dir改成对应的路径，比每次都用命令面板指定省事。项目一多起来，这种小习惯累积的收益其实挺明显的。