sublime text 不能就地调试，因其无容器运行时、不支持 docker exec 或 debug 接口，也不提供断点、变量监视或进程 attach；所谓“就地调试”实为编辑后快速触发容器内命令并查看输出的轻量级验证。
Sublime Text 不能做就地调试 —— 它没有容器运行时、不提供 docker exec 或 debug 接口，也不支持断点、变量监视或进程 attach。所谓“就地调试”，在 Sublime 里只能退化为「编辑 + 快速触发容器内命令 + 查看输出」，本质是轻量级交互式验证，不是 IDE 级调试。
为什么 Ctrl+B 执行 docker exec 总失败或卡住
docker exec 默认分配伪终端（-it），而 Sublime 的构建系统（Build System）不提供 TTY，强行加 -it 会导致命令挂起或报错 the input device is not a TTY。
实操建议：
- 去掉
-it，改用-i（仅 stdin）+-u（指定用户）+--env（传递环境变量）组合 - 命令必须以
sh -c包裹，否则 Sublime 不解析管道和重定向，比如docker exec myapp sh -c "python -m pdb app.py" - 避免交互式命令（如
bash、vim），它们会阻塞构建流程；可用cat /proc/1/cmdline或ps aux这类一次性命令验证容器状态 -
file_regex对exec输出无效——它只匹配编译类错误的路径+行号格式，调试输出日志无法跳转
怎样让 Sublime 编辑后一键进容器跑当前文件
关键不是“进容器”，而是把当前文件路径安全映射并执行。Sublime 提供$file 和 $file_path 变量，但它们在单引号中不展开，且容器内路径与宿主机不一致。
实操建议：
- 构建系统中用双引号包裹
cmd，确保$file被 shell 解析："shell_cmd": "docker exec myapp sh -c 'cd /app && python "${file/.*\///}"'" - 假设容器挂载了
-v $(pwd):/app，那么${file/.*\///}是取文件名（正则替换掉路径前缀），避免硬编码 - 若容器未挂载源码目录，该方式必然失败；必须提前确认
docker run命令含正确-v参数 - Python 文件需确保容器内有对应解释器和依赖，
exec不重建环境，不安装包
想看容器日志或实时输出怎么办
Sublime 的构建系统是单次执行、非流式输出，docker logs -f 会一直阻塞，导致构建界面无响应甚至卡死。
实操建议：
- 放弃在 Build System 中运行
-f类命令；改用docker logs --tail=50 myapp查最近日志 - 把日志命令写成独立 Build System，命名为
Logs.sublime-build，绑定快捷键（如Ctrl+Alt+L），避免和构建冲突 - 若真需实时流，用终端分屏（如 tmux 或 Windows Terminal）跑
docker logs -f，Sublime 专注编辑 - 日志中的错误行无法被
file_regex定位，因为格式是2026-06-30T13:20:45.123Z ERROR app.py:42 ...，需手动提取app.py:42
docker exec -it 进去手敲命令，或者换用 VS Code + Dev Containers。别指望 Sublime 补齐调试链路——它连进程生命周期都管不了。
