code runner 默认超时200ms会主动终止进程，必须手动在settings.json中配置"code-runner.timeout": 30000（毫秒）以支持python、php等启动较慢的语言，否则无法正常运行。
Code Runner 的 code-runner.timeout 必须手动设，否则 200ms 就杀进程
VSCode 的 Code Runner 插件对所有语言默认超时是 200 毫秒，不是卡死，而是主动 kill 子进程并报 “Time out”。Python、PHP、Node.js 带 I/O 或模块加载的脚本，连解释器启动都可能超 200ms，更别说执行逻辑。这个值不会随语言自动调整，也不识别文件后缀或内容，只认一个全局配置项：code-runner.timeout。
修改方式：打开 settings.json，添加或覆盖这一行：
"code-runner.timeout": 30000
单位是毫秒，30000 = 30 秒，足够覆盖绝大多数本地开发场景。改完必须保存并重试 Ctrl+Alt+N，无需重启 VSCode 全局，但旧终端实例里的进程不会自动续命。
- Windows 用户注意：
executorMap里路径别用反斜杠，统一用正斜杠/或双反斜杠\ - 如果设了
code-runner.runInTerminal: true，timeout 会失效——VSCode 无法监听新开终端里的子进程生命周期 - PHP 开了 Xdebug（尤其
xdebug.start_with_request = yes）时，建议至少设为5000，否则调试器初始化阶段就被砍掉
Cline 插件调用 Ollama 模型的 cline.apiTimeout
Cline 插件发起 HTTP 请求到本地 Ollama 服务时，超时由插件自身控制，和 Code Runner 无关。默认值通常较短（如 10000），在 SSH 远程开发、模型加载慢或网络抖动时极易触发。
直接在 settings.json 中添加：
"cline.apiTimeout": 60000
设为 60000（60 秒）能覆盖大多数 LLM 推理耗时。注意这不是服务器端超时，只是客户端等待响应的上限。
- 配合启用日志：
"cline.enableLogging": true+"cline.logLevel": "debug"，可确认请求是否发出、卡在哪一环 - 如果用了远程 SSH，优先排查网络延迟而非盲目加 timeout；本地直连 Ollama 成功但远程失败，基本可锁定是链路问题
- 该配置只影响 Cline 发起的 API 调用，不影响 Ollama 服务本身的
OLLAMA_TIMEOUT环境变量
文心快码插件的异步补全延迟，靠 wenxin.code.asyncCompletion 和 WebSocket
文心快码的补全卡顿，常被误认为是网络或模型慢，实际是默认 HTTP 轮询模式导致响应堆积。开启异步模式后，它会改用 WebSocket 长连接接收分片结果，大幅降低感知延迟。
两步走：
- 在设置中把
wenxin.code.asyncCompletion设为true - 项目根目录建
.wenxinrc.json，写入：{"async_mode": "websocket", "max_retry": 2}
不改配置只调大 timeout 没用——它解决的是传输模型，不是等得更久。WebSocket 连接建立后，即使单次响应慢，后续补全也能复用连接，避免反复握手开销。
超时改大了还是没用？先确认是不是根本没跑起来
很多“超时”问题本质不是时间不够，而是命令压根没执行成功。比如：
- Python 找不到模块，进程启动即退出，Code Runner 在 200ms 内就判定失败
- C++ 编译失败后静默退出，VSCode 认为“没输出=卡住”，立刻 kill
-
executorMap里写的python3在 Windows 上不存在，实际应为python
验证方法：复制 code-runner.executorMap 中对应语言的完整命令，在终端里手动执行一次，看是否真能跑出结果。别跳过这步——90% 的“timeout 无效”问题，根源都在这里。
