直接给对象的__proto__赋值在大型项目中大概率引发连锁故障：导致原型链循环卡死、性能断崖下降、环境兼容性问题及原型污染攻击面扩大，且错误难定位、复现不稳定。
直接给对象的 __proto__ 赋值，在大型项目中不是“可能出问题”，而是大概率引发连锁故障——它不报错就运行，一报错就整块逻辑崩掉，且难以定位。
原型链循环导致进程级卡死
一旦出现 obj.__proto__ = obj 或 child.__proto__ = parent 且 parent 原型链中已含 child，V8 等引擎会立即触发循环检测，抛出 RangeError: Maximum call stack size exceeded。这不是异步错误，而是同步阻断：如果发生在初始化、路由守卫或渲染前钩子中，整个页面会白屏无响应，DevTools 也失去调试能力。
- 这类循环很难静态发现，尤其在跨模块、动态构造原型链时（比如插件系统、低代码表单引擎）
- 错误堆栈往往只显示
at Object.setPrototypeOf，但真实源头是某处隐蔽的obj.__proto__ = ... - CI 环境和部分用户设备上复现率低，容易被误判为偶发崩溃
性能断崖式下降
现代 JS 引擎依赖隐藏类（Hidden Class）和内联缓存（IC）加速属性访问。修改 __proto__ 会让对象脱离优化路径，强制进入字典模式（dictionary mode）：
- 后续所有属性读写变慢 2–5 倍，高频操作（如列表渲染、动画帧计算）延迟明显
- 该对象参与的任何函数都会被去优化（deoptimize），V8 可能重新编译整段闭包
- 影响范围不限于当前对象——同原型链上的其他实例也会被波及
环境兼容性与静默失效
__proto__ 是附录 B 的遗留特性，非强制实现：
- Node.js 某些版本（如早期 14.x）、Web Workers、旧版 Safari 中赋值会静默失败或抛
TypeError - 严格模式下直接赋值非法，但若项目混用严格/非严格模块，错误可能只在部分文件生效
- 打包工具（如 Webpack、esbuild）做 dead code elimination 时，可能误删对 __proto__ 的存在性判断，导致生产环境行为突变
原型污染攻击面扩大
当外部数据（如 API 响应、URL 参数）被浅合并进配置对象时，__proto__ 键会被引擎识别为原型操作而非普通字段：
-
JSON.parse('{"__proto__": {"isAdmin": true}}')后再Object.assign({}, data)，会导致{}、new Date()、甚至fetch函数都继承isAdmin - 大型项目中常有多层 merge 工具（如 Lodash 的
merge），它们默认不过滤 __proto__，成为污染传导链 - 安全扫描工具通常只查
eval和Function，很少覆盖原型污染路径
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
