深度克隆本身不天然安全，关键看实现方式；若盲目遍历并设置__proto__、constructor等敏感属性，会污染原型链引发原型污染攻击，安全方案需拦截敏感路径、使用Object.create(null)或structuredClone()等。

深度克隆本身不天然安全，关键看实现方式。如果克隆过程盲目遍历并设置所有属性（包括 __proto__、constructor、prototype），就会把恶意键名原样复制到新对象上，进而污染其原型链——这就是原型污染攻击的典型入口。

为什么普通深拷贝容易触发原型污染

很多手写或旧版工具（如 lodash target[key] = clonedValue 赋值。当遇到 {"__proto__": {"isAdmin": true}} 这类输入时，target.__proto__ 就会被赋值，实际修改了 target 的隐式原型，而该原型又继承自 Object.prototype，导致后续所有普通对象都可能带上 isAdmin: true。

• JSON.parse() 后直接深拷贝，等于二次执行危险操作
• 只过滤顶层 __proto__ 不够，攻击者可用 "a.b.__proto__.c" 绕过
• 使用 Object.assign({}, obj) 浅拷贝也危险——它虽不递归，但若 obj 已被污染，目标对象仍会继承污染后的原型

安全深度克隆的核心防护点

真正安全的克隆必须在属性写入前主动拦截敏感路径，并切断原型继承链条：

• 递归过程中对每个 key 路径做正则扫描，例如 /\b(__proto__|constructor|prototype)\b/i，匹配即跳过
• 对 __proto__ 特殊处理：不用简单赋值，改用 Object.defineProperty(target, '__proto__', {...}) 控制行为
• 优先创建无原型对象作为克隆容器：Object.create(null)，从源头移除污染载体
• 避免依赖用户可控的 key 名动态赋值；必要时用白名单限定允许写入的字段

生产环境推荐的安全方案

不必自己重造轮子，优先选用经过安全验证的现成方案：

• klona/src/json.js：仅 28 行，专为 JSON 安全类型设计，显式防御 __proto__，适合配置类数据
• destr：解析 + 克隆一体化，默认过滤原型污染键，比 JSON.parse 更稳妥
• structuredClone()（现代浏览器/Node.js 17+）：原生 API，不走原型链，自动忽略不可序列化属性和敏感键
• jsondiffpatch.clone()：专为差异对比场景优化，内置深度克隆保护机制

额外加固建议

克隆只是防线一环，还需配合其他措施形成纵深防御：

• 接收 JSON 前先校验大小，防爆破式嵌套污染（如 JSON.stringify(data).length > 1024 * 1024 拒绝）
• 服务端路由层启用 JSON Schema 验证，从结构上拒绝含敏感字段的请求体
• 对配置类对象、插件注册表等关键字典，统一用 Object.create(null) 初始化
• 禁用 eval、Function 构造器，避免污染后执行任意代码