try...catch仅捕获同步错误，异步错误需await后才生效；仅在明确可能throw且能响应时使用，如JSON.parse、深层属性访问、localStorage操作等；catch参数须为变量名，不可写类型；finally仅用于无条件清理，禁用return或抛错。
try...catch 只能捕获同步错误，对异步错误（如未 await 的 Promise、setTimeout 里的 throw）完全无效——这是绝大多数人踩坑的起点。
什么时候必须用 try...catch？
不是所有代码都要包一层，只在明确知道某行会 throw，且你有能力响应时才用：
-
JSON.parse()：用户输入、localStorage 读取、后端返回脏数据时极易抛SyntaxError - 访问深层嵌套属性前：比如
user.profile.address.city，但user或中间某层可能是null，?.解决不了所有场景（如需 fallback 数据） -
localStorage.setItem()：用户禁用存储、配额超限会抛QuotaExceededError或SecurityError - 调用某些 Web API 同步失败时：如
navigator.clipboard.readText()在非安全上下文或权限拒绝时直接 throw
catch 参数怎么写？常见误写有哪些？
catch 后面括号里必须是变量名，不是类型声明。写成 catch (Error e) 或 catch (e: Error) 是语法错误（TypeScript 也不允许这样运行时写）。
- ✅ 正确写法：
catch (error)、catch (err)、catch (e)（推荐用error，DevTools 调试更清晰） - ❌ 错误写法：
catch (Error error)、catch (error instanceof Error) - 别空
catch：至少写console.error(error)，否则错误静默消失，后续排查无从下手 - 想区分错误类型？用
error.name === 'SyntaxError'比error instanceof SyntaxError更稳妥（跨 iframe / 模块时构造函数引用可能不同）
async/await 场景下 try...catch 怎么写才真正生效？
await 会让被 reject 的 Promise 表现得像同步错误，所以 try...catch 对它有效；但前提是——你真 await 了。
立即学习“Java免费学习笔记（深入）”；
- ✅ 正确：
const res = await fetch('/api');→ 网络失败、HTTP 404/500（需手动检查res.ok）都会进catch - ❌ 错误：
fetch('/api').then(...)套在try里 →catch完全不触发，Promise rejection 仍为 unhandled - 注意：
fetch默认不会因 HTTP 状态码 reject，必须自己加判断：if (!res.ok) throw new Error(`HTTP ${res.status}`) - 别把整个函数体塞进
try：只包裹真正可能出错的await行，否则堆栈难定位
finally 不是“善后万金油”，用错反而掩盖问题
finally 总会执行，但它不是用来做业务逻辑判断的，而是无条件清理。
- 适合：
setLoading(false)、clearTimeout(timer)、controller.abort()等确保状态还原的操作 - 危险操作：
finally里写return会覆盖try或catch的返回值；写throw会吞掉原始错误 - 别在
finally里发请求、调用可能出错的 API —— 它不该引入新异常 - 即使
try和catch都有return，finally里的return仍会生效，这点极容易被忽略
最常被低估的点：try...catch 不是兜底开关，而是精准拦截器。包得太大，问题定位变难；包得太小，漏掉关键异常；不加 finally 清理 loading 状态，UI 就卡死；在 finally 里随便 return，函数行为就不可预测。
