try-catch仅捕获同步异常，因基于调用栈机制，异步任务（如settimeout、promise）脱离其上下文；需用async/await、.catch()或回调内try-catch处理异步错误。
try-catch 只能捕获同步执行过程中抛出的异常，它不负责“监听”后续异步任务里的错误——不是它不想管，而是执行流早就离开了它的作用域。理解这点，是写出可靠错误处理逻辑的前提。
为什么只抓同步错误？
JavaScript 的 try-catch 是基于当前调用栈（call stack）工作的。一旦代码进入异步队列（如 setTimeout 回调、Promise 微任务、fetch 响应处理），就脱离了原始 try 块的执行上下文。即使你在 try 里启动了一个异步操作，那个操作内部抛错，也不会回到原来的 catch 里。
- 同步示例有效：JSON.parse('{"a":}')、obj.unknown.prop、1/0 这类立刻执行并报错的操作，会被正常捕获
- 异步示例无效：setTimeout(() => { throw new Error() })、fetch().then(...).catch(...) 外层套 try，catch 不会触发
-
常见误解：以为
try { fetch(...) }能捕获网络失败——其实 fetch 本身几乎总返回 Promise，不抛异常；错误发生在后续 resolve/reject 阶段
异步错误的正确捕获方式
不能靠“包一层”解决，得把 try-catch 放到真正可能出错的同步执行点上，或借助 Promise 原生机制。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- async/await 场景：在 async 函数中 await Promise，此时 reject 会被转换为 throw，从而被外层 try-catch 捕获
-
Promise 链场景：用
.catch()显式处理拒绝状态，尤其适合非 async 环境或需要链式响应时 - 回调函数内：比如事件监听器、setTimeout 回调、Node.js 回调等，需各自内部加 try-catch
哪些地方值得加 try-catch？
不是所有代码都要包，重点覆盖已知易错、且你能合理响应的同步环节：
- JSON.parse() 解析用户输入或接口返回的字符串
- 访问深层嵌套对象属性（如
data?.user?.profile?.name不够时，用 try 保底） - 读写 localStorage（可能因配额满或跨域限制失败）
- 调用第三方库中明确文档标注“可能 throw”的方法
别踩这些坑
看似省事，实则掩盖问题或制造新问题：
- 顶层盲目包裹：比如整个 script 标签用 try-catch 包住——语法错误、异步错误全漏掉，还让真实错误更难定位
- finally 里 return：会覆盖 try 或 catch 中的返回值，导致逻辑异常
- catch 里不做任何事：空 catch 块等于静默吞错，调试时毫无线索
-
混淆 fetch 错误类型：fetch 返回的 Response 对象即使 status=404 或 500，也不会自动 reject，需手动检查
response.ok或response.status
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
