new.target 无法防止异步构造函数被劫持，因 javascript 不支持 async constructor；它仅能防护 new 调用路径的入口伪造，需结合静态工厂冻结、环境校验、懒初始化和代码完整性校验等多层策略。
new.target 本身不能“完美防止”异步构造函数被恶意劫持，因为 JavaScript 中异步构造函数在语言层面根本不存在——constructor 必须是同步的，不能用 async 修饰。所谓“核心加密异步构造函数”，实际是开发者把异步初始化逻辑（如密钥派生、远程密钥获取、证书校验等）塞进构造函数或封装成类似构造行为的工厂方法。真正需要防护的是这类带敏感初始化的类实例化过程，而 new.target 只是其中一环辅助手段，需配合其他机制才能形成有效防护。
为什么 async constructor 不合法？
ECMAScript 明确禁止 async constructor：
- 构造函数必须返回一个对象（或显式返回其他对象），而
async函数总是返回Promise； -
new Foo()语义上要求立即获得实例，无法等待 Promise resolve； - 尝试写
class X { async constructor() {} }会直接语法报错。
典型危险模式：伪异步构造 + 静态工厂滥用
常见错误写法：
class CryptoEngine {
constructor() {
// ❌ 错误：试图在构造中 await（语法不允许）
// await this.init();
}
static async create() {
const inst = new CryptoEngine();
await inst.init(); // ✅ 合法，但 create 方法可被覆盖
return inst;
}
async init() {
this.key = await deriveKey(...); // 敏感操作
}
}
问题在于：CryptoEngine.create = evilOverride 可轻易劫持，绕过任何校验逻辑。
用 new.target 做基础防篡改（仅限 new 调用路径）
new.target 在构造函数内指向当前 new 调用的目标构造器。可用于阻止子类或代理劫持实例化入口：
class CryptoEngine {
constructor() {
// ✅ 检查是否直接通过 new CryptoEngine() 调用
if (new.target !== CryptoEngine) {
throw new TypeError('Direct instantiation only. Subclassing forbidden.');
}
// ✅ 防止 Reflect.construct 或 new Proxy 模拟
if (typeof new.target !== 'function' || new.target.name !== 'CryptoEngine') {
throw new TypeError('Invalid constructor invocation');
}
}
}
注意：new.target 对 static create() 无效，它不进入构造函数，所以该检查只保护 new 路径。
真正有效的组合防护策略
单靠 new.target 远不够。需多层加固：
-
禁用静态工厂覆盖：用
Object.defineProperty冻结CryptoEngine.create，并设writable: false, configurable: false； -
运行时环境校验：检测
globalThis.Proxy是否被篡改、Function.constructor是否原始、是否处于调试器中（如getEventListeners存在且非 undefined）； - 延迟敏感初始化：不在构造/工厂中执行关键操作，改为首次调用加密方法时 lazy-init，并用私有 Symbol 标记状态，避免重复或提前触发；
-
代码完整性绑定：对关键方法体做哈希（如
crypto.subtle.digest），启动时校验自身函数源码未被 patch（需配合模块完整性或 SRI）。
new.target 是一道轻量但明确的门禁，它不防逻辑劫持，只防调用入口伪造。核心加密流程的安全，终究依赖分层设计、最小信任暴露和运行时自检，而非某个语法特性。
