try catch仅捕获同步异常（如JSON.parse失败、访问undefined属性），不捕获SyntaxError、异步错误、未await的Promise拒绝及资源加载失败；需小范围包裹、明确响应、正确处理async/await与finally清理。
try catch 能捕获哪些错误？
它只捕获同步抛出的异常（throw）和运行时同步错误，比如 JSON.parse() 解析失败、访问 undefined 的属性、调用未声明函数等。它**不捕获**：SyntaxError（语法错误，如少括号，只在 eval 中可捕获）、异步回调里的 throw（如 setTimeout(() => { throw new Error() })）、未 await 的 Promise 拒绝、资源加载失败（img.onerror 之类）。
- ✅ 正确场景：解析用户输入的 JSON 字符串、读取深层嵌套对象（
user.profile.address.city）、调用可能失败的浏览器 API（如navigator.clipboard.readText()） - ❌ 错误期待：把整个
fetch().then()链塞进try块里，指望外层catch捕获网络错误——它不会生效 - ⚠️ 注意：
fetch本身网络中断会进catch，但 HTTP 404/500 不会自动 reject，必须手动检查response.ok并throw
怎么写一个真正有用的 try catch？
核心是「小范围、有目的、有响应」：只包裹 1–2 行真正可能出错的代码，且你在 catch 里能做点事——降级、提示、上报，而不是空着或只打个日志就扔掉。
- 必须写
catch (error)，不能省略参数；推荐用error而非e，方便调试工具识别 -
error.message是最简明的错误描述，优先用它；error.stack含位置信息，上线建议采集并上报 - 别把整个函数体包进去——定位困难、掩盖真实问题点
- 示例（安全解析 + 降级）：
try { const data = JSON.parse(userInput); return data; } catch (error) { console.warn('JSON 解析失败，使用默认配置', error.message); return { theme: 'light', lang: 'zh' }; }
async/await 场景下 try catch 怎么用才不翻车？
这是现代 JS 最常用也最容易出错的组合。await 会让被 reject 的 Promise 表现得像同步错误，从而被 catch 捕获；但前提是——你真用了 await，且没漏掉任何一环。
- ✅ 正确写法：
const res = await fetch('/api');→await res.json();，两处都await，HTTP 错误和 JSON 解析错误都能进catch - ❌ 典型翻车：
fetch('/api').then(r => r.json())放在try里——catch完全收不到错误，因为 Promise 已脱离同步执行流 - ⚠️ 注意：如果
catch里需要向上冒泡，记得throw error或包装后重抛，别静默吞掉 - 示例（带 HTTP 状态检查）：
async function loadConfig() { try { const res = await fetch('/config.json'); if (!res.ok) throw new Error(`HTTP ${res.status}`); return await res.json(); } catch (error) { console.error('配置加载失败', error); return getDefaultConfig(); } }
finally 到底该干啥？哪些事千万别做
finally 的唯一使命是「无条件清理」：无论成功、失败、还是提前 return，它都执行。但它不是兜底业务逻辑的地方，更不是返回值的“最终仲裁者”。
立即学习“Java免费学习笔记（深入）”；
- ✅ 推荐用途：关闭 loading 状态、清除定时器（
clearTimeout(timer)）、还原 UI 类名、释放AbortController - ❌ 危险操作：在
finally里return—— 它会覆盖try或catch中的返回值；在finally里再抛错 —— 会吞掉原始错误，让调试雪上加霜 - ⚠️ 关键细节：即使
try里写了return 'ok'，finally仍会先执行；若finally也有return，那函数最终就返回它的值
最容易被忽略的点是：finally 的清理逻辑必须是「幂等且无副作用」的——比如重复调用 clearTimeout 没问题，但重复调用一次性的 API 就可能引发意外行为。
