vscode插件网络请求超时需用abortcontroller手动控制，因原生fetch不支持timeout选项；必须在finally中结束withprogress，且插件不继承全局代理，须显式读取http.proxy配置并传入请求库。
VSCode 插件开发中，网络请求的延迟与超时不是“加个 timeout 就完事”的问题——它直接影响用户对插件响应性的感知，且错误处理不当会导致命令卡死、UI 冻结、甚至 Extension Host 崩溃。
如何正确设置 fetch / axios 请求的超时边界
Node.js 环境（Extension Host）不支持原生 fetch 的 timeout 选项，直接传 { timeout: 5000 } 会被忽略。必须手动封装或用 AbortController 控制生命周期。
- 推荐用
AbortController+setTimeout组合：在请求发起前创建控制器，setTimeout触发abort()，并在catch中识别domexception: abort或AbortError - 避免用
axios的timeout配置：它底层依赖XMLHttpRequest，在 Extension Host 中不可靠；某些版本会静默失败，不抛异常 - 若用
node-fetch（需显式npm install node-fetch），注意它默认不带 AbortController 支持，必须传入signal选项，且要确保版本 ≥3.0
超时后 UI 状态如何安全恢复
插件常在命令触发后立即调用 vscode.window.withProgress 显示加载动画，但超时发生时若未主动结束该 Progress，动画会一直转圈，用户无法重试或取消。
- 务必在
finally块中调用progress.report({ increment: 100 })或直接 resolve 掉 progress 回调 - 不要仅依赖
then/catch：超时可能发生在 DNS 解析、TLS 握手等阶段，这些不会进入catch，只有AbortController能覆盖全链路 - 对长时间任务（如上传大文件），应提供
vscode.ProgressOptions.location: vscode.ProgressLocation.Notification并启用cancelable: true，让用户能手动中断
为什么代理配置失效？插件发请求不走 VSCode 全局代理
VSCode 的 http.proxy 设置只影响内置功能（如 Marketplace、自动更新），**不自动透传给插件进程**。插件内所有 fetch、https.request 等调用默认绕过代理，直连目标地址。
- 必须在插件代码中显式读取并应用代理：用
vscode.workspace.getConfiguration('http').get('proxy')获取值，再传给请求库（如node-fetch的agent选项） - 代理 URL 必须含协议前缀：
http://127.0.0.1:7890，写成127.0.0.1:7890会被忽略 - HTTPS 代理需支持 CONNECT 方法；若用 Charles/Fiddler 类工具，还需额外处理证书：设
rejectUnauthorized: false（仅限开发环境）并确保系统信任其根证书
如何避免高延迟请求阻塞其他插件功能
一个慢请求（如等待第三方 API 返回）若在主线程同步等待，会拖垮整个 Extension Host，导致其他插件命令无响应。这不是并发问题，而是单线程事件循环被占满。
- 禁用
require('child_process').execSync或任何同步 I/O；所有网络请求必须异步 - 对非关键请求（如后台上报、埋点），使用
setTimeout(() => { /* request */ }, 0)延迟调度，避免抢占当前 tick - 用
vscode.env.asExternalUri替代自行拼接跳转链接：它会自动处理代理、认证和跨域策略，减少自定义请求需求
最易被忽略的一点：VSCode 不会为插件请求自动重试。超时或 5xx 错误后是否重试、重试几次、间隔多久，全部得你自己实现——而且重试逻辑必须带退避（exponential backoff），否则可能触发服务端限流，让问题更糟。
