new.target 可用于区分直接调用与子类继承调用，从而实现错误类的分级日志：若 new.target === AppError 则拒绝实例化，否则读取子类 static level 属性决定日志级别。
在全栈框架中，new.target 可以用来区分“直接 new 调用”和“被子类继承后调用”，从而实现错误日志类的分级实例化——比如让 BadRequestError 自动打 warn 级日志，InternalServerError 自动打 error 级，而基类 AppError 不直接记录（防止误用）。关键不是“能不能用”，而是怎么用得干净、可维护、不侵入业务逻辑。
用 new.target 区分构造意图，避免基类被误实
基类 AppError 本身不应直接记录日志，否则 new AppError('xxx') 就会触发默认 error 日志，掩盖真实错误级别。通过 new.target === AppError 判断是否为“裸调用”，就能拒绝或降级处理：
- 若
new.target === AppError，抛出TypeError或静默转为Info级别（视团队规范） - 若
new.target !== AppError，说明是子类实例化，此时可安全读取子类上的静态属性（如level = 'warn'）来决定日志行为
子类声明日志级别，基类统一接管日志逻辑
每个业务错误子类只需声明自己的语义级别，无需重复写日志代码。例如：
（Node.js / TypeScript 示例）class AppError extends Error {
constructor(message, opts = {}) {
super(message);
this.code = opts.code;
this.status = opts.status || 500;
if (new.target === AppError) {
throw new TypeError('AppError 是抽象基类，请使用具体子类');
}
const level = new.target.level || 'error';
log(level, {
message,
code: this.code,
stack: this.stack,
timestamp: Date.now()
});
}
}
class BadRequestError extends AppError {
static level = 'warn';
constructor(message, opts = {}) {
super(message, { status: 400, code: 'BAD_REQUEST', ...opts });
}
}
class ValidationError extends BadRequestError {
static level = 'info'; // 细粒度覆盖
}
前后端共用时注意运行时差异
浏览器中 new.target 支持良好（ES6+），但 SSR 或某些打包配置下（如 Webpack 的 target: 'node' + module: 'commonjs'）可能因 Babel 转译丢失 new.target。应对策略：
- 构建时确保未启用破坏性转换（如
@babel/plugin-transform-classes默认保留new.target） - 服务端加 fallback：检查
this.constructor.name是否为'AppError'，作为new.target不可用时的兜底判断 - 全栈项目中，建议将错误类定义放在
shared/目录，并用tsconfig.json的composite: true和引用路径保障类型与行为一致
配合中间件/拦截器自动注入上下文
仅靠 new.target 还不够——真实场景需要请求 ID、用户身份、API 路径等上下文。可在基类构造函数中尝试从全局执行上下文（如 Node 的 async_hooks、Express 的 res.locals、或前端 React context）提取信息，再合并进日志对象：
- Node 环境：利用
AsyncLocalStorage在请求生命周期内透传reqId、userId - 前端：若在 React 中抛错，可结合
ErrorBoundary捕获后补全路由和组件名 - 注意避免强耦合：用可选依赖注入（如传入
getTraceContext函数），而非硬编码调用特定框架 API
