AI 摘要：本文介绍了在 JavaScript (ES2022) 中引入的 Error.cause 属性，展示它如何让错误处理更具可追溯性。作者 Matt Smith 通过实例说明了传统错误包裹的缺陷，以及 Error.cause 在保持原始堆栈信息、改进调试体验和测试断言方面的优势。最终总结出一套现代错误链最佳实践，帮助开发者构建更清晰、更稳健的错误追踪体系。

1. 传统错误处理的问题
• 层层调用的代码容易丢失原始错误信息；
• 以字符串拼接错误信息会破坏堆栈和错误类型；
• 导致调试困难，追踪难度高。

2. 引入 Error.cause 的改进
• 通过 new Error(message, { cause }) 保留原始错误；
• 可同时访问顶层与底层堆栈信息；
• cause 属性为非枚举属性，不污染日志或循环输出；
• 与 message、stack 一样保持一致的行为。

3. 实践与代码演示
• 示例：从 JSON.parse 到自定义函数的错误传递；
• 在日志中手动输出 err.cause 获取完整上下文；
• 适合层次式系统（如服务嵌套调用）排查问题。

4. 历史背景与 cause 出现前的替代方案
• 旧方案包括自定义字段 .originalError、字符串拼接等；
• 这些方式不统一且容易破坏原始错误结构；
• 标准化的 cause 提供更安全一致的机制。

5. 自定义错误类的支持
• 在自定义类中通过 super(message, { cause }) 传递原因；
• 适用 ES2022+ 环境即可直接使用；
• 对 TypeScript 用户，需在 tsconfig.json 中启用 "target": "es2022" 与 "lib": ["es2022"]。

6. 在测试中的应用
• 测试断言可直接验证 err.cause 类型；
• 提升测试可读性与准确性。

7. 实用技巧与注意事项
• 浏览器默认不输出层级错误链，须手动打印；
• 不建议过度使用错误链，避免干扰阅读；
• 可递归打印完整错误链（logErrorChain 与 logFullErrorChain 示例）；
• 实践场景：数据库异常→业务异常→服务异常的多层错误追踪。

8. 环境支持与现代用法总结
• 支持于现代浏览器与运行环境（Chrome 93+、Node.js 16.9+、Deno、Bun 等）；
• 推荐实践：
• ✅ 使用 Error(message, { cause })
• ✅ 支持内建与自定义错误类型
• ✅ 改善日志和调试体验
• ✅ 对 TypeScript 进行正确配置
• ⚠️ 记得手动输出或递归追踪错误链。