`try/catch` 只能捕获 `throw` 抛出的异常，无法捕获函数直接 `return` 的 `error` 对象；若需统一处理，须显式判断返回值是否为 `error` 实例并手动 `throw`。
在 JavaScript 开发（尤其是构建 NPM 包）中，常需对异常进行健壮处理。但一个常见误区是：误以为 try/catch 能捕获所有“错误形态”——包括函数返回的 Error 对象。实际上，try/catch 的作用域仅覆盖同步抛出（throw）的异常，而 return new Error(...) 本身是合法的正常执行流程，不会触发异常机制，因此绝不会进入 catch 块。
例如，以下代码看似“返回错误”，实则完全绕过 try/catch：
let returnError = () => new Error("I broke out!");
try {
let res = returnError(); // ✅ 正常执行，res 是一个 Error 实例
console.log("This line runs — no error was thrown!");
result = res;
} catch (err) {
// ❌ 永远不会执行
}
// → Uncaught Error: "I broke out!"？不！这里根本不会报错——但后续若尝试使用 res 作为值，可能引发隐式问题⚠️ 注意：上述代码并不会崩溃（除非你在后续操作中 throw res 或误用该 Error 对象），但它确实“漏掉了错误意图”——开发者本意可能是将 Error 视为失败信号，却未做任何检查。
✅ 正确做法是：在 try 块内主动识别返回的 Error 实例，并显式 throw，使其落入 catch 流程：
立即学习“Java免费学习笔记（深入）”；
let result;
const returnError = () => new Error("I broke out!");
try {
const res = returnError();
// 关键检查：是否返回了 Error 实例？
if (res instanceof Error) {
throw res; // ? 主动抛出，交由 catch 处理
}
result = res;
} catch (err) {
result = {
message: err.message,
name: err.name,
stack: err.stack // 可选：保留原始堆栈信息
};
}
console.log(result);
// → { name: "Error", message: "I broke out!", stack: "..." }? 进阶建议：
- 若函数约定“失败时返回 Error”，可封装统一的调用工具函数，避免重复判断；
- 更推荐的工程实践是：统一使用 throw 表达失败（符合 JS 异常语义），或采用 Result
类型（如通过 true-myth 或自定义），而非混用 return Error； - 在 TypeScript 中，可通过返回联合类型 T | Error 配合类型守卫强化检查，但运行时仍需手动判别。
总结：try/catch 不是万能的“错误拦截器”，它是异常控制流机制，而非值校验工具。理解 throw 与 return 的本质区别，才能写出可预测、易维护的错误处理逻辑。
