JS中删除原型链上的属性，答案是可以使用delete操作符直接删除，但强烈不建议这样做，因为这会影响所有继承该原型的实例并可能引发难以追踪的bug；1. 可以通过delete myObject.prototype.propname删除原型上的属性，使其对所有实例不可访问；2. 不建议这样做的原因是它会影响所有现有和未来的实例、破坏继承结构、导致调试困难且可能影响性能；3. 更推荐的做法是在实例上创建同名属性来“屏蔽”原型属性，实现属性遮蔽，从而不影响其他实例，若需恢复访问原型属性，可删除实例上的同名属性。
JS中删除原型链上的属性，说实话，这事儿听起来简单，但背后牵扯的学问和潜在的“坑”可不少。核心观点是：虽然你可以用
delete
操作符直接删除原型链上的属性，但强烈不建议这么做，因为它会影响所有继承该原型的对象，并可能导致意想不到的副作用和难以追踪的bug。多数情况下，你真正想做的，是在实例上“覆盖”或“屏蔽”原型上的属性，而不是真正地“删除”它。
解决方案
要“删除”原型链上的属性，你确实可以直接对原型对象本身使用
delete
操作符。这听起来很直接，比如你有一个构造函数
MyObject
，它的原型上有一个属性
myProp
，你想删掉它，你会这么做：
function MyObject() { this.instanceProp = '我是一个实例属性'; } MyObject.prototype.myProp = '我是一个原型属性'; MyObject.prototype.anotherProp = '另一个原型属性'; const obj1 = new MyObject(); const obj2 = new MyObject(); console.log(obj1.myProp); // 输出: 我是一个原型属性 console.log(obj2.myProp); // 输出: 我是一个原型属性 // 核心操作：删除原型上的属性 delete MyObject.prototype.myProp; console.log(obj1.myProp); // 输出: undefined console.log(obj2.myProp); // 输出: undefined console.log(MyObject.prototype.myProp); // 输出: undefined
你看，
delete MyObject.prototype.myProp
这一行代码，确实让
myProp
从
MyObject.prototype
上消失了，也因此，所有继承自
MyObject.prototype
的实例（比如
obj1
和
obj2
）都无法再访问到这个属性了。它就像从根源上把这棵“继承树”上的某个“果实”给摘掉了。
为什么不建议直接删除原型链上的属性？
在我看来，直接在原型链上删除属性，就像是在一个共享的公共图书馆里，你直接把某本书撕掉了几页。虽然你可能觉得你只是删掉了不想要的部分，但问题是，所有依赖这本书的人都会受到影响，而且他们可能根本不知道发生了什么，直到他们发现自己要用的内容突然不见了。
具体来说，不建议这么做的原因有：
- 影响所有实例（现有和未来）：原型是所有实例共享的。一旦你从原型上删除了一个属性，所有通过这个原型创建出来的实例，以及将来会创建的实例，都将失去这个属性。这会带来非常难以预测的后果，尤其是在大型应用中，你可能不知道哪些模块或组件正在依赖这个属性。
- 破坏继承结构和预期行为：JavaScript的继承机制就是基于原型链的。属性查找是沿着原型链向上进行的。如果你随意删除原型上的属性，就可能破坏了原有的继承关系，导致代码的行为与开发者预期不符。比如，某个方法本来应该存在于原型上，被实例调用，你一删除，方法就找不到了，直接报错。
- 调试困难：当一个属性突然“消失”时，排查问题会变得非常困难。你可能需要花大量时间去追溯是谁、在什么时候、以什么方式删除了这个属性，而不是像实例属性那样，一眼就能看出是哪个实例的问题。
- 性能考量：虽然这通常不是首要原因，但在某些JavaScript引擎内部，对原型链的修改可能会导致优化被取消，从而影响性能。
所以，我个人觉得，除非你对代码库有100%的掌控，且非常清楚自己在做什么，否则这种操作是应该尽量避免的。
如何在实例上“屏蔽”原型链上的属性？
这才是大多数情况下，我们真正想要达到的效果。你不是想从原型上彻底抹去一个属性，而是想让某个特定的实例表现得好像没有这个原型属性，或者用一个自己的属性来替代它。这在JS里叫做“属性遮蔽”（shadowing）或“覆盖”（overriding）。
方法很简单，你只需要在实例对象上直接赋值一个同名属性即可：
function MyObject() { this.instanceProp = '我是一个实例属性'; } MyObject.prototype.myProp = '我是一个原型属性'; MyObject.prototype.anotherProp = '另一个原型属性'; const obj1 = new MyObject(); const obj2 = new MyObject(); console.log(obj1.myProp); // 输出: 我是一个原型属性 console.log(obj2.myProp); // 输出: 我是一个原型属性 // 在obj1实例上“屏蔽”myProp obj1.myProp = '我是一个obj1实例上的myProp'; console.log(obj1.myProp); // 输出: 我是一个obj1实例上的myProp (原型上的被屏蔽了) console.log(obj2.myProp); // 输出: 我是一个原型属性 (obj2不受影响) // 验证：obj1.hasOwnProperty('myProp')会是true，而obj2.hasOwnProperty('myProp')会是false console.log(obj1.hasOwnProperty('myProp')); // true console.log(obj2.hasOwnProperty('myProp')); // false // 如果你想让obj1再次访问原型上的myProp，只需删除obj1实例上的myProp delete obj1.myProp; console.log(obj1.myProp); // 输出: 我是一个原型属性 (又可以看到原型上的了)
通过这种方式，
obj1
现在有了自己的
myProp
属性，当访问
obj1.myProp
时，JS引擎会首先在
obj1
自身上查找，找到了就不会再沿着原型链向上查找了。而
obj2
则完全不受影响，它依然能够访问到原型上的
myProp
。这种做法既安全又灵活，符合我们对实例独立性的预期。
理解
delete
delete
操作在原型上的行为及其潜在风险
我们已经知道，
delete
操作符可以从对象中移除属性。当这个对象是原型时，它确实会移除原型上的属性。但我们需要更深入地理解它的行为边界和风险。
delete
操作符只能删除对象自身的可配置属性（configurable property）。如果一个属性是不可配置的，
delete
操作符将无效，并且在严格模式下会抛出错误。然而，大多数我们手动添加到原型上的属性，默认都是可配置的。
// 示例：delete操作的边界 const proto = {}; Object.defineProperty(proto, 'fixedProp', { value: '我不可删除', configurable: false // 设置为不可配置 }); proto.deletableProp = '我可以删除'; console.log(proto.fixedProp); // 我不可删除 console.log(proto.deletableProp); // 我可以删除 delete proto.fixedProp; // 尝试删除不可配置属性 delete proto.deletableProp; // 删除可配置属性 console.log(proto.fixedProp); // 仍然是: 我不可删除 (删除失败) console.log(proto.deletableProp); // undefined (删除成功)
虽然理论上你可以通过
Object.defineProperty
让原型上的属性不可删除，但这通常不是我们处理原型属性的常规做法。
真正的风险在于，当你在一个共享的原型上执行
delete
操作时，你实际上是在改变一个“全局”的状态。这就像你修改了一个所有人都依赖的公共API。如果你的代码库中其他部分或者第三方库依赖于这个被删除的属性，那么它们就会突然崩溃，而且这种崩溃往往发生在运行时，难以在开发阶段通过静态分析发现。这种行为在协作开发或者维护大型项目时，几乎可以算是一种“反模式”。因此，我的建议是，除非有极其特殊且你完全掌控的场景，否则请避开直接在原型上使用
delete
。
