object.seal仅阻止增删属性和修改属性描述符，但不冻结可写属性的值，无法真正防篡改；需配合object.freeze、私有字段、校验方法等分层控制。
用 Object.seal 防止状态机结构被篡改，是个常见但容易误用的做法。它确实能阻止新增、删除属性，也能防止重配置现有属性的描述符（如 writable、configurable），但它不冻结属性值本身——也就是说，只要属性是可写的，它的值仍可被修改。所以仅靠 seal 无法真正“防篡改”，必须配合其他手段。
明确 seal 的能力边界
Object.seal 只作用于对象自身的属性，不影响原型链；它让所有自有属性变成 configurable: false，同时保留 writable 状态不变。这意味着：
- 不能添加新属性（
obj.newProp = 1失败，严格模式报错） - 不能删除已有属性（
delete obj.prop返回false） - 不能改变属性的
configurable或enumerable特性 - 但若属性原本
writable: true，其值仍可赋值覆盖（obj.state = 'idle'依然生效）
封死状态机结构 + 值变更需分层控制
一个健壮的状态机，核心要约束的是：状态集合不可增删、状态转移逻辑不可绕过、当前状态值不可随意写入。仅 seal 远不够，推荐组合策略：
- 用
Object.freeze替代seal封禁所有属性（包括值），适用于状态枚举对象（如{ IDLE: 'idle', LOADING: 'loading' }） - 对状态机实例，把状态值存在
WeakMap或闭包私有变量中，暴露的 getter/setter 做校验和流转控制 - 用
Object.seal封住状态机的配置对象（如 transitions 表），再用Object.freeze深冻每个 transition 条目 - 所有状态变更必须通过
transitionTo()方法触发，内部校验合法性，拒绝非法跃迁
实际封装示例（轻量级防篡改状态机）
以下是一个兼顾密封性与可控性的实现片段：
class SafeStateMachine {
#state = 'idle';
#transitions = new Map();
constructor(initialState, config) {
// 冻结配置，防止 transition 规则被改
const sealedConfig = Object.freeze(
Object.fromEntries(
Object.entries(config).map(([from, rules]) => [
from,
Object.freeze(rules)
])
)
);
// 构建只读 transitions 映射
for (const [from, rules] of Object.entries(sealedConfig)) {
this.#transitions.set(from, Object.freeze(rules));
}
// 初始化并 seal 实例自身（禁止新增/删属性）
Object.seal(this);
this.#state = initialState;
}
get state() { return this.#state; }
transitionTo(next) {
const rules = this.#transitions.get(this.#state);
if (!rules || !rules[next]) {
throw new Error(`Invalid transition: ${this.#state} → ${next}`);
}
this.#state = next;
return this;
}
}
这样，外部无法增删属性、无法修改 #transitions 结构，也无法绕过 transitionTo 直接赋值 #state（私有字段+无 setter）。
警惕常见陷阱
开发者常忽略的几个风险点：
-
Object.seal(obj)不递归作用于嵌套对象——如果状态机里有普通对象属性，它们仍可被任意修改 - 使用
Proxy拦截 set/get 是更灵活的方案，但开销略高；seal是零成本基础防线，应作为第一道屏障 - 不要依赖
seal防止原型污染，它不影响__proto__或prototype；必要时用Object.setPrototypeOf(obj, null)切断原型链 - 在模块打包后，tree-shaking 可能移除未使用的私有字段或方法，建议配合 TypeScript 类型守卫 + 运行时 assert 双保险
