VSCode无法全自动为所有async函数加try-catch，因错误处理需依赖业务语义；所谓“自动”插件仅简单包裹，不识别await位置、嵌套Promise或throw来源；手动多光标+正则替换最可控，但需先明确策略；真正有效的是ESLint规则、全局unhandledrejection监听及团队Promise返回约定。
VSCode 没有插件能全自动给所有 async 函数加 try-catch
这不是功能缺失，而是设计上不可行：async 函数的错误处理逻辑高度依赖业务语义（比如哪些错误该重试、哪些要告警、哪些直接吞掉），强行套用统一模板反而会掩盖真实问题。你看到的“自动加 try-catch”类插件（如 error-catcher 或 trycatch）实际只做简单包裹，不识别 await 位置、不处理嵌套 promise、不区分 throw 来源，生成的代码大概率不能用。
手动批量添加 try-catch 的安全做法
用 VSCode 自带的多光标 + 查找替换最可控，适用于已明确异常处理策略的项目（例如统一转成 Result 类型或记录日志后 re-throw）：
- 先用正则查找所有 async 函数开头：
async\s+(function|const|let|var)\s+\w+|async\s+\w+\s*=\s*async，勾选「使用正则表达式」和「在文件中查找」 - 逐个点击匹配项，按
Ctrl+D（Win）或Cmd+D（Mac）选中多个函数声明，再按Ctrl+Shift+Right跳到函数体左大括号{后，回车换行，输入try { - 把光标移到函数体末尾（大括号前），回车，输入
} catch (err) { console.error(err); } - 注意避开箭头函数简写形式（如
const fn = async () => doSomething()），这种无法直接插入块，必须先扩写成const fn = async () => { return doSomething(); }
真正值得投入的自动化替代方案
与其补救式加 try-catch，不如从源头降低异常失控风险：
- 在 ESLint 中启用
@typescript-eslint/no-misused-promises和promise/no-nesting，提前拦截未处理的 promise rejection - 用
unhandledrejection全局监听器兜底（仅限浏览器环境）：window.addEventListener('unhandledrejection', e => { /* 上报或降级 */ }); - Node.js 项目统一用
process.on('unhandledRejection', ...)，配合async_hooks追踪异步上下文 - 团队约定：所有导出的 async 函数必须返回
Promise<result e>></result>（类似 Rust 的 Result），由调用方决定如何解包 —— 这比到处写 try-catch 更易维护
为什么「自动包裹」在 TypeScript 里尤其危险
TypeScript 的类型检查不会因加了 try-catch 就自动修正返回类型。比如原函数返回 Promise<string></string>，加上 try-catch 后若没显式 return，实际返回 Promise<void></void>，但 TS 不报错，运行时可能触发 Cannot read property 'then' of undefined 这类隐蔽问题。
更麻烦的是 await 在 try 块内外行为差异：如果把 await apiCall() 放在 try 外，reject 会直接冒泡；放在 try 内，错误被吃掉但返回值变成 undefined —— 插件不可能替你判断该放哪。
复杂点在于：异步错误的位置、传播路径、恢复策略，本质上不是语法问题，是架构决策。工具能帮的只有减少手误，没法代替思考。
