安全控制中心的核心是明确分工、严格时序、各守边界：冻结 Function.prototype 等关键原型兜底防御，setPrototypeOf 仅在冻结前用于可信对象的隔离增强，二者分层设防不可混用。
利用 Object.setPrototypeOf 和 Object.freeze 协同构建安全控制中心，核心不是“组合使用”，而是**明确分工、严格时序、各守边界**。二者本质冲突：一个动态改原型，一个永久锁结构。强行混用不仅无效，反而引入漏洞。真正的协同在于用冻结守住关键防线，用 setPrototypeOf 在可控前提下做有限增强，且必须规避其风险。
冻结 Function.prototype 是不可协商的起点
所有函数行为（包括事件监听、定时器回调、模块导出等）都依赖 Function.prototype。一旦它被篡改（如 toString、call 被重写），整个执行链就可能被劫持。防御必须在任何第三方脚本运行前完成：
- 在
<head>中首个内联<script>里执行Object.freeze(Function.prototype) - 该操作不可逆，后续任何属性增删改都会在严格模式下抛出
TypeError - 冻结后仍可正常使用
new Function()或定义新函数——constructor不受影响，只是原型本身不可变
setPrototypeOf 只用于可信、一次性、可验证的增强
Object.setPrototypeOf 本身不安全，但若严格限定使用场景，可为安全机制提供轻量扩展能力：
- 仅在冻结前使用（如初始化阶段），且目标对象是明确受控的内部工具对象，非用户输入或第三方实例
- 例如：为自研日志收集器实例挂载统一审计方法，原型来自内部定义的纯净
AuditMixin对象 - 禁止对 DOM 元素、全局对象、第三方库实例调用该方法——它们可能已被污染或存在优化陷阱
- 每次调用后应校验：
Object.getPrototypeOf(target) === expectedPrototype，防止静默失败
冻结后禁止任何形式的原型修补
一旦 Function.prototype 或关键内置原型（如 Array.prototype）被冻结，setPrototypeOf 对这些对象本身将失效（严格模式报错，非严格模式静默忽略）。这不是 bug，而是设计保护：
- 不要尝试用
setPrototypeOf“修复”已被污染的原型——冻结后无法覆盖，强行操作会失败或绕过校验 - 若发现原型已被篡改，唯一可靠做法是在冻结前拦截（如通过 CSP 阻断恶意脚本）、或从 iframe 提取干净引用做还原（非 setPrototypeOf 方式）
- 把
setPrototypeOf视为“初始化期的构造辅助”，而非“运行时的补丁工具”
真正协同的关键：用冻结兜底，用 setPrototypeOf 做隔离增强
二者协同不是在同一对象上叠加，而是分层设防：
- 底层：冻结
Function.prototype、Array.prototype等，切断全站逻辑劫持路径 - 中层：用
Object.create(null)创建无原型对象作为配置/策略容器，避免继承污染 - 上层：对内部可信模块实例，可在冻结前用
setPrototypeOf统一注入审计或沙箱方法，但该原型自身也需冻结 - 全程配合 CSP（禁用
unsafe-eval）、SRI 校验、禁用eval等，形成纵深防御
