VSCode提示“timeout waiting for debugger connection”主因是调试器连接等待超时，需优先检查terminal.integrated.shell.windows路径是否完整（如"C:WINDOWSSystem32cmd.exe"）、launch.json中timeout字段是否显式设为30秒以上，并重启集成终端。
VSCode 运行代码时提示“timeout waiting for debugger connection”或保存/运行卡在“launching…”，通常不是代码问题，而是终端启动链路断裂或调试器连接等待时间过短。关键不在“编译超时”，而在于 VSCode 启动 Python（或其他语言）进程时，**等不到子进程回传调试端口或就绪信号**——这个等待窗口默认极短，且极易被错误的 shell 路径、权限拦截或路径拼写问题直接堵死。
terminal.integrated.shell.windows 路径必须完整且可执行
Windows 下 VSCode 默认用 terminal.integrated.shell.windows 指定终端程序，但很多用户只填了 cmd.exe，没带完整路径。VSCode 会尝试在 PATH 中查找，一旦环境变量污染或 PATH 被重置（比如装 Git 时勾选了“Use Windows default console”），就可能找不到或加载失败。
- 正确写法是：
"terminal.integrated.shell.windows": "C:\WINDOWS\System32\cmd.exe"（注意双反斜杠） - 不要写成
cmd.exe、C:Windowscmd.exe或PowerShell.exe（除非你明确配置了 PowerShell 的调试支持） - 如果使用 WSL，该设置不生效；需改用
terminal.integrated.defaultProfile.linux并确认 WSL 发行版已安装 python3 和 ptvsd / debugpy - 改完后必须重启集成终端（关闭所有 Terminal 标签页，再 Ctrl+Shift+` 重新打开），仅保存 settings.json 不够
debugpy 启动慢或卡住时，要调的是 launch.json 的 timeout，不是 editor 设置
很多人搜“VSCode 修改超时时间”，误去改 editor.codeActionsOnSave.timeout 或 editor.suggestDelay，这些和运行/调试完全无关。真正控制调试器连接等待的是 Python 扩展的 launch.json 配置项。
- 在项目根目录下确保有
.vscode/launch.json，内容包含类似：
{
"version": "0.2.0",
"configurations": [
{
"name": "Python: Current File",
"type": "python",
"request": "launch",
"module": "debugpy",
"justMyCode": true,
"console": "integratedTerminal",
"env": {},
"subProcess": true,
"timeout": 30
}
]
}
"timeout": 30 单位是秒，指 debugpy 等待调试端口就绪的最大时间；默认值常为 10～15，大项目或远程解释器建议设为 30～60"type": "python" 生效；若用 "type": "pwa-node" 或其他调试器，对应字段名不同（如 webBrowserLaunchUrlTimeout）launch.json，VSCode 会用内置默认配置，无法调整 timeout —— 必须手动创建并指定保存时自动格式化/检查引发的“伪超时”，改 codeActionsOnSave.timeout
另一种常见假象：你按 Ctrl+S 后界面卡住 1–2 秒，状态栏显示 “Running code actions on save…”，最后报错 “codeActionsOnSave timeout”。这不是运行超时，而是保存时触发的 ESLint、Prettier、autopep8 等操作耗时太久。
- 控制该行为的配置是：
editor.codeActionsOnSave.timeout，单位毫秒，默认 750 - 可在
settings.json中设为更高值，例如："editor.codeActionsOnSave.timeout": 3000 - 更治本的做法是精简
editor.codeActionsOnSave列表，例如只保留"source.fixAll.python"，禁用"source.organizeImports"（它在大型项目中极易超时） - 注意：此 timeout 和调试器无关，改它不会解决
timeout waiting for debugger connection
真正卡住的地方往往藏在路径拼写、shell 权限、debugpy 版本兼容性这三层之下。先确认 C:\WINDOWS\System32\cmd.exe 能手动双击运行，再检查 launch.json 是否存在且 timeout 已显式声明，最后才排查扩展冲突——顺序错了，花半天调参数也没用。
