应避免直接修改 __proto__，因其会强制V8重建隐藏类，导致JIT优化失效、属性访问变慢及去优化；推荐用Object.setPrototypeOf替代，但仅限初始化阶段；优先采用组合而非原型链变更。
直接修改 __proto__ 会强制 V8 为对象切换隐藏类，破坏已有的 JIT 优化，导致属性访问变慢、内联失效甚至去优化（deoptimization）。这不是“不推荐”，而是明确应避免的模式。
根本原因：__proto__ 修改触发隐藏类重建
V8 为每个对象结构分配一个隐藏类（Hidden Class），用于快速定位属性偏移量。一旦执行 obj.__proto__ = newProto，V8 就判定该对象“结构已变”，立即废弃原有隐藏类，生成新类并重新编译相关函数——所有依赖原结构的优化全部失效。
即使只改一次，也会让该对象及其后续同类实例无法复用已有隐藏类路径，尤其在高频对象创建场景下影响显著。
用 Object.setPrototypeOf 替代 __proto__ 赋值
Object.setPrototypeOf(obj, proto) 和直接赋 __proto__ 效果相同，但它是标准方法，语义更清晰；更重要的是，它能被静态分析工具识别，便于团队规范约束。
- ✅ 允许但不鼓励：仅在极少数必须动态变更原型链的初始化阶段使用（如构建特定兼容层）
- ❌ 禁止在循环、事件回调、渲染帧等高频路径中调用
- ⚠️ 注意：它同样会触发隐藏类变更，不能解决根本问题，只是更规范的写法
优先采用组合而非原型链变更
绝大多数需要“动态行为”的场景，其实不需要改原型——用委托或属性代理更稳定、更可控。
- 把共用逻辑封装成独立工具对象，通过
this.utils.method()调用，不污染实例结构 - 用
Map或闭包缓存行为配置，按需返回不同策略函数，避免运行时改原型 - 对多态需求，用工厂函数返回预设好原型的对象，确保所有实例从构造起就共享同一隐藏类
构造阶段一次性设定原型（安全可行）
如果确实需要自定义原型，唯一安全的方式是在对象创建瞬间完成，且全程保持结构一致：
- ✅ 使用
Object.create(proto)创建对象，原型在诞生时即确定 - ✅ 构造函数中用
Object.setPrototypeOf(this, CustomProto)（仅限首行，且所有实例都执行） - ❌ 不要在实例化后、属性已设置再改
__proto__或调用setPrototypeOf - ❌ 避免混用：一部分实例用
Object.create，另一部分用new后手动设原型
用 --trace-deopt 验证是否触发去优化
启动 Node.js 时加上 --trace-deopt 参数，运行关键逻辑，观察控制台输出是否有类似 [marking dependent code for deoptimization] 的日志。若出现，说明隐藏类已被破坏，需回溯代码中是否存在 __proto__ 或 setPrototypeOf 调用。
配合 Chrome DevTools 的 “Optimization tab” 可直观查看函数是否处于 optimized 状态。
