Object.seal仅提供浅层防护，需三层协同：封结构、冻嵌套、断引用；扁平配置用freeze，动态场景用Proxy，生成器工具依赖内置校验。
Object.seal 本身不能“完美”防止 Generator 核心配置被篡改，它只提供浅层结构防护：禁止添加/删除属性、禁止重配置已有属性描述符（如 writable、configurable），但允许修改可写属性的值。若配置对象含嵌套对象、数组或函数，仅 seal 并不足够——业务层仍可通过 config.db.url = 'hacked' 或 config.features.push('malicious') 改动内容。
真正防篡改的关键是组合策略
seal 是必要但非充分手段。要让 Generator 的核心配置具备生产级防篡改能力，需三层协同：
-
第一层：冻结基础结构 —— 对配置对象本身调用
Object.seal(config)，确保 key 集合与属性元信息不可变 -
第二层：冻结嵌套可变值 —— 若 config 含子对象（如
{ db: { host: 'x' } }）或数组（如features: ['a']），必须递归 seal 或 freeze 这些值；否则 seal 失效 -
第三层：切断原始引用出口 —— 所有对外暴露的 getter（如
getConfig()）必须返回深拷贝或冻结副本，绝不能返回内部 config 的直接引用
典型破功场景与修复方式
以下写法会让 seal 形同虚设：
- 在闭包中
const config = { db: {} }; Object.seal(config); return { config };→ 外部拿到res.config.db仍可自由修改 -
getFeatures() { return this.config.features; }→ 返回的是原数组，push/splice全部生效 - 用
const声明 config 但未 seal/freeze →const只锁变量绑定，不锁对象内容
正确做法：在 getter 中返回不可变视图，例如
return Object.freeze({ ...config, features: Object.freeze([...config.features]) });比 seal 更强的替代选择
当配置结构较深或含特殊类型（Date、Map、Set）时，seal + 手动递归成本高且易漏。推荐按场景选型：
- 扁平配置 + 简单嵌套 →
Object.freeze（比 seal 更严，还禁止写入） - 需运行时动态更新 → 用
Proxy实现只读代理，拦截 set/delete 操作并抛错 - 生成器类工具（如 projen、MBG）→ 依赖其内置机制：文件只读权限 + 自动生成标记 + 构建时完整性校验
- Java 环境类似需求 → 不用 seal，改用
Collections.unmodifiableMap+ 独立副本 + static final
