sublime构建系统原生不支持timeout参数，需通过shell封装实现跨平台超时控制：macos/linux用gtimeout命令，windows用powershell的start-process -timeoutsec，并统一使用shell_cmd模式配合shell:true配置。
Sublime构建系统本身不支持timeout参数
直接在 .sublime-build 文件里加 "timeout": 30 或类似字段——它会被完全忽略。Sublime Text 的原生 exec 构建目标（即默认的 "target": "exec"）没有超时控制机制，既不会杀掉卡住的子进程，也不会抛出超时异常。这是设计使然，不是配置遗漏。
真正可行的跨平台方案：用 shell 封装命令 + timeout 工具
核心思路是把 Python（或其他解释器）调用包进一层可中断的外壳命令中，由系统级工具负责超时和终止。不同系统对应不同命令：
- macOS / Linux：用
timeout命令（GNU coreutils 提供，macOS 需先brew install coreutils，然后用gtimeout） - Windows（CMD）：没有原生
timeout支持，但可用start /wait /b+timeout /t组合，稳定性差；更可靠的是用 PowerShell 的Start-Process -Wait -TimeoutSec
示例（macOS/Linux）：
{
"shell_cmd": "gtimeout 10s python3 -u \"$file\" || echo \"[TIMEOUT] Process killed after 10 seconds\"",
"file_regex": "^[ ]*File \"(*?)\", line ([0-9]*)",
"selector": "source.python",
"encoding": "utf-8"
}
注意：gtimeout 必须已安装且在 $PATH 中；"shell_cmd" 模式下，变量如 $file 是 shell 层解析的，需用双引号包裹并转义引号；错误提示字符串会原样输出到面板，便于识别是否真超时。
Windows PowerShell 方案必须显式指定 shell
PowerShell 超时逻辑不能靠 cmd 字段触发，必须走 shell_cmd 并声明 "shell": true，否则 Sublime 会尝试以数组方式执行，失败且无报错：
{
"shell_cmd": "powershell -Command \"try { Start-Process -FilePath 'python' -ArgumentList '-u', '$file' -Wait -TimeoutSec 10 } catch { Write-Host '[TIMEOUT] Process killed' }\"",
"shell": true,
"selector": "source.python",
"encoding": "utf-8"
}
常见坑：
-
Start-Process -TimeoutSec在某些旧版 PowerShell（ -
$file在 PowerShell 字符串中会被提前展开，必须写成'$file'（单引号）防止被 PS 解析 - 若 Python 脚本本身有交互输入（如
input()），PowerShell 的-Wait可能卡住，此时应改用Start-Job+Wait-Job异步模式，但复杂度陡增
超时后残留进程得手动清理
即使 timeout 或 Start-Process 返回了，子进程未必真正退出——尤其当它 spawn 了子子进程（如调用 subprocess.Popen 后没设 shell=True 或没处理 preexec_fn=os.setsid）。这意味着你下次运行可能撞上“Address already in use”或文件被占用等错误。
补救办法（仅限 macOS/Linux）：在 shell_cmd 末尾追加清理逻辑，例如
"shell_cmd": "gtimeout 10s python3 -u '$file'; pkill -f 'python3.*$file' 2>/dev/null"
Windows 下等效操作更脆弱，taskkill /F /T /IM python.exe 会杀掉所有 Python 进程，不推荐用于多项目并行开发环境。
最稳的方式其实是避免依赖超时——把长任务拆成可中断的单元，或改用 LSP + debug adapter 等支持软中断的插件链。构建系统本就不是为长时间运行服务的，硬加超时只是权宜之计。
