object.freeze()通过向v8提供不可变性信号，优化逃逸分析与隐藏类判定：冻结对象更易被判定为不逃逸，支配链更短、retained size更小，新生代驻留时间延长，避免过早晋升；需验证隐藏类名含frozen、支配树结构简化及分配火焰图中newspace占比提升。
Object.freeze() 本身不直接改变垃圾回收行为，但它通过向 V8 提供强不可变性信号，显著影响逃逸分析、对象内联和标记阶段的判定逻辑。要证实它带来的扫描优化，不能只看“回收更快”，而需在堆快照中观察其对对象图结构、支配关系、保留大小和晋升路径的实际影响。
确认 freeze 后对象是否进入“可优化路径”
V8 对冻结对象启用特殊隐藏类（如 FROZEN_OBJECT_SLOW 或 FROZEN_LITERAL），这类类在字节码编译和内联缓存中被标记为“无动态属性风险”。验证方法：
- 在 DevTools Memory 面板中录制两个快照：一个在 freeze 前（刚创建但未冻结），一个在 freeze 后（立即 freeze 并保持引用）
- 切换到 Containment（遏制）视图，展开该对象 → 查看其
[[Prototype]]和constructor字段；若显示为Object且隐藏类名含frozen或literal，说明已走优化路径 - 对比相同结构未 freeze 的对象——后者通常显示更复杂的隐藏类链，且可能带
DICTIONARY_ELEMENTS或HAS_SLOW_ELEMENT_DICTIONARY标记
观察支配树（Dominator Tree）中引用强度变化
冻结对象因字段不可变，V8 在逃逸分析中更倾向判定其“不逃逸”，从而缩短其支配链。这会直接反映在快照的 Dominators Tree 中：
- 在快照中定位该 frozen 对象 → 右键 → “Reveal in Dominators Tree”
- 对比 unfrozen 版本：frozen 对象的支配者往往更靠近根（如直接由 closure 或 module scope 支配），而非被中间 wrapper、proxy 或 event handler 层层包裹
- 若 frozen 对象的 Retained Size 显著低于 unfrozen 版本（尤其嵌套深时），说明 V8 成功剪枝了部分间接引用路径——这是扫描负担降低的直接证据
检查新生代存活周期与晋升延迟
不可变对象更易被 V8 判定为“短命但稳定”，从而延长其驻留新生代时间，避免过早晋升至老生代。验证方式：
- 在 Chrome DevTools 的 Memory > Allocation instrumentation on timeline 中开启记录，触发多次小规模操作（如创建 + freeze + 短暂使用）
- 停止录制后，在分配火焰图中筛选该对象构造函数（如
createPoint工厂函数）→ 观察其分配位置：若绝大多数出现在NewSpace区域，且 没有连续多次出现在 OldSpace 分配线，说明晋升被有效抑制 - 配合
--trace-gc日志查看：frozen 对象在 Scavenge 中被复制次数减少，且极少触发promotion记录
排除干扰：确保 freeze 真正生效且无副作用
很多“无效 freeze”会破坏优化效果，快照中会出现反向线索：
- 若对象含 getter/setter 或 Proxy，快照中该对象的
[[Get]]或[[Set]]属性会显示为native或bound，且其 Retained Size 异常偏高（因闭包捕获外部变量） - 若 freeze 后仍尝试赋值（哪怕失败），V8 会为其创建过渡隐藏类，快照中可见多个同名构造器实例，且类型标注为
OBJECT而非FROZEN_OBJECT - 嵌套对象未递归 freeze 时，快照中会显示子对象仍为普通
Object类型，且其支配者链明显长于父对象——说明 V8 无法整体推断不可变性
