自定义错误类堆栈丢失的根源是 this.stack 未正确初始化，需在构造函数中显式设置 this.name 并用 error.capturestacktrace（node.js）或 new error().stack.replace（浏览器）重置 stack，且包装错误时须保留原 stack。
自定义错误类继承 Error 后堆栈信息丢失或不准确，不是“硬伤”，而是实现细节没到位。关键在于 this.stack 没被正确初始化或覆盖，导致调用位置、构造位置混淆，尤其在多层抛出或旧环境（如某些 Node.js 低版本、老版 Safari）中更明显。
必须显式设置 this.name 并触发 stack 初始化
仅写 super(message) 不足以让所有环境生成完整堆栈。浏览器和现代 Node.js（v10+）通常能自动补全，但一旦中间有异步跳转、Promise 链、或被包装过，this.stack 就可能只显示“抛出点”，而非“构造点”。解决方法是：在构造函数末尾主动重置 stack。
- 推荐兼容写法：
this.stack = new Error().stack.replace(/^Error/, this.name); - 不要直接赋值
this.stack = super().stack——super()返回的是 undefined，不能链式调用 -
this.name必须设为字符串（如"ValidationError"），否则instanceof成立但日志里仍显示Error
Node.js 环境优先用 Error.captureStackTrace
Node.js 提供了标准 API 来精确控制堆栈起点，比手动字符串替换更可靠、更语义化。
- 在子类构造函数中调用：
Error.captureStackTrace(this, CustomError); - 第二个参数指定“忽略该函数及之上的调用帧”，确保 stack 从
new CustomError(...)开始，而不是从super()内部开始 - 注意：此方法仅 Node.js 支持，浏览器中需降级处理（如上面的
replace方案）
避免堆栈被二次覆盖的常见陷阱
堆栈丢失往往不是继承本身的问题，而是后续操作无意覆盖了原始 stack。
- 不要在 catch 块里
throw new CustomError(...)包装原错误却不保留原 stack —— 这会彻底丢失上下文 - 若需包装，应显式继承原 error 的 stack：
this.stack = originalError.stack;或拼接：this.stack = `${this.stack}\nCaused by: ${originalError.stack}` - 避免在构造函数外修改
this.stack；所有修正逻辑必须在构造函数内完成
验证是否生效的简单方式
不用等线上出问题，本地加一行测试即可：
- 实例化后立即打印：
console.log(new ValidationError("test").stack); - 确认首行是
ValidationError: test，且第二行起包含你期望的文件名与行号（如at foo.js:12:5） - 在 Promise 链或 async 函数中抛出并捕获，检查 stack 是否仍指向构造位置，而非
await或.then处
