检测 JavaScript 原型是否被密封最直接的方法是使用 Object.issealed()，它会返回一个布尔值表示对象是否被密封；2. 密封对象后不能添加或删除属性，但可以修改现有属性值，而冻结对象（object.freeze()）则完全禁止修改；3. 密封操作不影响原型链上的属性查找，实例仍可正常继承和访问原型方法，且可在实例上覆盖方法而不影响被密封的原型。
检测 JavaScript 原型是否被密封，最直接的方法就是使用
Object.isSealed()
这个内置函数。你只需要把目标原型对象作为参数传进去，它就会返回一个布尔值，告诉你这个原型是不是已经被“锁”起来了。
Object.isSealed()
是专门用来检查一个对象是否被密封的。当一个对象被密封后，你不能再添加新的属性，也不能删除已有的属性。但是，现有属性的值是可以被修改的。这和冻结（
Object.freeze()
）不同，冻结是连修改都不允许。
举个例子，假设我们有一个构造函数
MyClass
，它的
就是我们想检测的对象：
function MyClass() { this.value = 1; } // 正常情况下，原型是可以被修改的 console.log(Object.isSealed(MyClass.prototype)); // false // 我们可以给原型添加一个方法 MyClass.prototype.getValue = function() { return this.value; }; // 现在我们来密封它 Object.seal(MyClass.prototype); console.log(Object.isSealed(MyClass.prototype)); // true // 尝试添加新属性（会失败，严格模式下报错） try { MyClass.prototype.newValue = 2; } catch (e) { console.log("尝试添加新属性失败:", e.message); // TypeError: Cannot add property newValue, object is not extensible } // 尝试删除已有属性（会失败，严格模式下报错） try { delete MyClass.prototype.getValue; } catch (e) { console.log("尝试删除已有属性失败:", e.message); // TypeError: Cannot delete property 'getValue' of #<Object> } // 但是，修改现有属性的值是允许的 MyClass.prototype.getValue = function() { return this.value + 10; }; console.log(new MyClass().getValue()); // 11
我个人觉得，理解这些“锁”的级别非常重要，它决定了你的对象能有多大的灵活性或者说有多大的“安全感”。
密封原型和冻结原型有什么区别？
这个问题其实挺核心的，也是很多人容易混淆的地方。说白了，密封（
Object.seal()
）和冻结（
Object.freeze()
）都是对对象可变性的一种限制，但它们限制的程度不一样，就像是给房子上锁，有的是只锁大门，有的是连窗户都焊死了。
Object.seal()
： 当你对一个对象执行
Object.seal()
后，这个对象就不能再添加新的属性了，也不能删除已有的属性。但是，它现有属性的值还是可以被修改的。你可以想象成，这个对象的“骨架”被固定了，不能增减成员，但成员的“内容”可以变。这在一些库或者框架中，为了保证核心API的稳定性和可预测性，但又允许用户配置部分行为时，可能会用到。
Object.freeze()
： 而
Object.freeze()
就要严格得多。它在
Object.seal()
的基础上，进一步禁止了对现有属性值的修改。也就是说，一个被冻结的对象，你既不能添加、删除属性，也不能修改任何已有属性的值。它就成了一个真正意义上的“不可变”对象。如果你想创建一个完全不可变的数据结构，比如配置对象或者枚举值，
Object.freeze()
是你的首选。
还有个
Object.preventExtensions()
，这个是最宽松的，它只阻止你添加新属性，删除和修改都还行。所以，这三者的严格程度是：
preventExtensions
<
seal
<
freeze
。在实际开发中，我遇到过一些新手，分不清这几个，结果导致对象行为不如预期，调试起来还挺费劲的。
为什么需要检测原型是否被密封？
在日常的javascript开发中，我们可能不会频繁地去检测一个原型是不是被密封了，但总有一些场景，这种检测能力会变得非常有用，甚至可以说是必要的。
一个很重要的原因是防御性编程。想象一下，你正在开发一个库或者框架，你对外暴露了一些构造函数，它们的
prototype
是你内部逻辑的关键部分。如果你不希望外部代码随意地给你的原型添加或删除属性，从而破坏你的内部机制或者引发不可预测的副作用，那么你可能会选择密封它。这时候，检测
isSealed
就能让你在某些关键操作前，确认原型的状态，避免不必要的错误。比如，你某个模块依赖于原型上某个方法的存在，如果这个方法被删除了，整个模块就可能崩溃。通过检测，你可以提前抛出错误或者采取补偿措施。
再比如，在调试复杂系统时，如果一个对象表现出奇怪的行为，比如某个属性突然不见了，或者无法添加新属性，那么检查它的原型是否被密封，可以帮助你快速定位问题。这就像是你在排查一个机器故障，发现某个零件无法拆卸或更换，你就会去检查是不是有什么特殊的锁具限制了它。
另外，代码审计或安全性检查时，也可能需要关注这一点。特别是当你的代码运行在共享环境中，或者需要确保某些核心对象的完整性时，检测原型状态能提供一层额外的保障。我曾经在维护一个遗留项目时，发现有些核心对象被意外地修改了，后来才发现是某个第三方库在不经意间对原型进行了操作。如果当时有机制去检测并限制，也许就能避免很多麻烦。
密封操作对原型链上的属性查找有何影响？
这是一个非常好的问题，因为它触及到了JavaScript原型链的核心机制。简而言之，对一个原型对象执行密封操作（
Object.seal()
），并不会直接影响到通过原型链进行的属性查找行为。
让我们来拆解一下：
当一个对象
obj
试图访问一个属性
prop
时，JavaScript引擎会首先在
obj
自身上查找
prop
。如果找不到，它就会沿着
obj
的原型链向上查找，直到找到
prop
或者到达原型链的顶端（
）。这个查找过程是只读的，它只是在“寻找”属性，而不是在“修改”任何东西。
现在，假设
MyClass.prototype
被密封了。这意味着：
- 你不能给
MyClass.prototype
添加新的属性。
- 你不能从
MyClass.prototype
删除已有的属性。
- 你可以修改
MyClass.prototype
上现有属性的值。
但这些限制都只作用于
MyClass.prototype
这个对象本身。对于那些通过
new MyClass()
创建出来的实例对象来说，它们从
MyClass.prototype
继承属性的机制并没有改变。
举个例子：
function Base() {} Base.prototype.baseMethod = function() { return "I'm from Base"; }; Object.seal(Base.prototype); // 密封 Base 的原型 function Derived() {} Derived.prototype = Object.create(Base.prototype); // Derived 继承自 Base 的原型 Derived.prototype.constructor = Derived; const instance = new Derived(); // 属性查找依然正常工作 console.log(instance.baseMethod()); // "I'm from Base" // 实例对象自身仍然可以添加新属性 instance.myOwnProperty = "hello"; console.log(instance.myOwnProperty); // "hello" // 实例对象自身仍然可以修改继承来的属性（如果该属性在实例自身上没有，会创建新的） instance.baseMethod = function() { return "I'm overridden in instance"; }; console.log(instance.baseMethod()); // "I'm overridden in instance" (这是在实例上创建了一个新方法，而不是修改了 Base.prototype 上的方法) console.log(Base.prototype.baseMethod()); // "I'm from Base" (Base.prototype 上的方法未变)
你看，即使
Base.prototype
被密封了，
instance
依然能够通过原型链访问到
baseMethod
。密封只是限制了
Base.prototype
这个对象自身的结构变动，而没有影响到原型链的查找行为。它更像是一个“自我保护”机制，确保原型对象本身的完整性，而不是影响其继承者的行为自由度。所以，如果你想限制实例对象的行为，你需要对实例对象本身进行操作，或者在构造函数中进行更细致的控制。这块内容，我觉得在实际项目中，尤其是在设计复杂继承体系的时候，理解透彻了能避免很多不必要的坑。
