Sublime Text 本身不提供运行日志或控制台，仅通过构建系统显示外部命令的单次输出快照；实时日志需借助Terminus插件、系统终端或日志文件重定向查看。
Sublime Text 本身没有运行日志或控制台
Sublime Text 是编辑器，不是 IDE，它不执行代码、不启动进程、也不内置 Python/Node/Java 运行时。所谓“软件运行控制台”，其实是你运行的外部程序（比如 python script.py）输出的日志，Sublime 本身并不捕获或展示这些——除非你主动配置构建系统或装插件。
常见误解：点菜单 Tools → Build 后底部出现的面板，只是 Sublime 执行完一条命令后的标准输出快照，不是实时日志流，也不能交互输入。
- 没装插件时，
Ctrl+B（Windows/Linux）或Cmd+B（macOS）只调用构建系统，输出完就停，不持续监听 - 想看 Web 服务日志？得去终端里跑
npm start或python manage.py runserver，Sublime 不会自动转发 - 想调试 Python 脚本？默认构建系统用的是
python -u，但没断点、没变量监视、没调用栈
用 Terminal 或 Console 插件看实时日志更靠谱
如果你真需要在 Sublime 界面里盯日志（比如本地启动了 webpack-dev-server 或 flask run），推荐两个轻量方案：
-
Terminus插件（推荐）：安装后按Ctrl+Shift+P→ 输入Terminus: Open Default Shell in Panel，就能在底部开个类终端面板，直接运行npm run dev，日志实时滚动，支持 Ctrl+C 中断 - 系统终端 + 文件监视：用
tail -f logs/app.log或journalctl -u myservice -f，再把日志文件拖进 Sublime 查看——简单、稳定、无兼容问题 - 别用
SublimeREPL：已多年未维护，对 Python 3.11+ 和 macOS Sonoma 兼容差，容易卡死或报UnicodeDecodeError
Build System 配置不当会导致日志截断或编码错乱
Sublime 的构建系统（.sublime-build）如果写得不严谨，输出中文日志可能变 ，长日志可能被截断，甚至根本看不到错误。
- Windows 上跑 Python 脚本，必须加
"encoding": "cp936"或"utf-8"（取决于系统 locale），否则中文报错信息显示为乱码 - Linux/macOS 下避免用
shell_cmd直接写python xxx.py，改用cmd+ 数组形式，能更好传递参数和环境变量 - 日志过长时，Sublime 默认只缓存最后 200 行，可在设置里加
"max_lines": 5000，但别设太大，否则卡 UI - 示例片段（Python 构建系统）：
{ "cmd": ["python", "-u", "$file"], "file_regex": "^[ ]*File \"(...*?)\", line ([0-9]*)", "encoding": "utf-8", "max_lines": 2000 }
调试代码别依赖 Sublime 的 Build 输出
Build 面板本质是单次命令执行结果，它不支持输入、不能重试、无法查看内存状态，也看不到异步回调里的 console.log 或 print() ——除非你把它们全打到 stdout。
- 前端调试 JS：浏览器 DevTools 的
Console面板才是正解；console.log在 Sublime Build 里根本不会出现 - 后端调试 Python：用
breakpoint()+ptvsd或 VS Code 的调试器；Sublime 没原生调试协议支持 - 临时加日志？可以，但记得用
print(..., flush=True)，否则缓冲区不吐出来，Build 面板就卡住不动 - 真正要“看日志”，不如把输出重定向到文件：
"cmd": ["python", "-u", "$file", ">", "debug.log", "2>&1"]，然后用 Sublime 打开debug.log
Sublime 的定位就是快速编辑和轻量任务调度，强行让它扛 IDE 的活，配置成本远高于收益。日志在哪产生，就在哪看——终端、浏览器、系统日志服务，才是它的自然归宿。
