Sublime Text构建系统非终端模拟器，多线程爬虫因输出缓冲、编码不匹配、无实时刷新及异常捕获缺失导致无响应或乱码；根本解法是改用Terminus插件或外部终端。
Sublime Text 本身不支持交互式输入，多线程爬虫脚本中的 input()、sys.stdin.read() 会直接报错或卡死；控制台输出默认不实时刷新、不捕获插件日志、不显示中文、也不支持滚动回溯——这不是你的代码问题，是 Sublime 的运行机制限制。
为什么 Ctrl+B 运行多线程爬虫后控制台没反应或乱码
Sublime 的构建系统（Build System）本质是调用外部 Python 进程并捕获其一次性 stdout/stderr 快照，不是终端模拟器。多线程爬虫大量并发打印时，输出可能：
- 被缓冲未及时刷出（尤其 Windows 下无
-u参数时） - 编码不匹配导致中文显示为
\xe4\xbd\xa0\xe5\xa5\xbd或问号 - 多线程交叉写入造成日志混行、截断或丢失
- 异常堆栈被吞掉（比如未加
try/except的子线程错误不会透出到控制台）
根本解法不是“修输出”，而是换执行环境：用 Terminus 插件开真终端面板，或改用外部终端（如 VS Code 终端、iTerm2、Windows Terminal）。
如何让多线程爬虫在 Sublime 中真正可调试
若坚持在 Sublime 内部调试，必须绕过构建系统的单次快照局限，转而依赖控制台（Ctrl + `）+ 插件日志 + 主动输出控制：
- 在爬虫脚本开头加
import sys; sys.stdout.reconfigure(line_buffering=True)（Python 3.7+），强制行缓冲 - 所有日志统一走
print(f"[{threading.current_thread().name}] {msg}", flush=True)，显式flush=True - 启用插件日志转发：菜单
Tools → Developer → Log Console Messages勾选，否则print()在插件上下文里静默丢弃 - 捕获子线程异常：用
threading.excepthook或在线程函数内包try/except并手动print(traceback.format_exc()) - 避免在构建系统中用
subprocess.run(..., shell=True)调外部命令——它会继承 Sublime 的受限环境，PATH 和编码都不可靠
构建系统 JSON 配置关键字段怎么填才不踩坑
你写的 Python3.sublime-build 文件，这几个字段直接影响多线程脚本能否看清、跑稳：
-
"cmd"：务必包含-u（unbuffered），例如["python3", "-u", "$file"]；Windows 用户若用cmd /k python ...方式，需额外加chcp 65001 > nul &切 UTF-8 -
"encoding"：显式设为"utf-8"，否则 Windows 默认 GBK 会解码失败 -
"working_dir"：设为"$file_path"，避免相对路径导入失败 -
"shell"：仅当cmd是字符串（非列表）时设为true；多线程脚本建议用列表形式，避免 shell 解析歧义 - 别加
"quiet": true或"target"字段——它们会屏蔽输出或重定向到错误位置
哪些操作看起来“能跑”，实则埋雷
这些常见做法在单线程脚本里可能凑合，在多线程爬虫里极易失效：
- 用
SublimeREPL运行当前文件：该插件已多年未维护，Python 3.11+ 下常因UnicodeDecodeError卡死，且不支持线程安全输出 - 在构建系统里调用
start cmd /k python $file：新开窗口无法与 Sublime 同步，关窗即丢日志，且 Windows 杀毒软件常拦截 - 依赖
sys.stderr.write()而不用print(..., file=sys.stderr)：前者不自动换行、不触发 flush，多线程下极易粘连 - 把日志写进
sublime.status_message()：只显示一行，长度受限，且不保留历史 - 在
ThreadPoolExecutor的submit()里传裸函数而不包装异常：子线程崩溃无声无息，主流程还继续 submit
最稳妥的路径是：用 Terminus 开终端面板执行脚本，或直接切到系统终端。Sublime 的控制台和构建系统，本质是给“单次、轻量、无交互”的脚本用的——爬虫不属于这个范畴。
