1. 背景与目标
1.1 为什么要让原型链上的属性不可配置
在 JavaScript 的原型链模型中，属性既可以是自有属性也可以来自原型对象。将原型链上的某些属性设为不可配置，能够防止它们被重新定义、删除或以不同的描述符修改，从而提升代码的健壮性和安全性，避免某些外部代码意外地破坏对象的行为。
本文的核心目标是展示如何通过 Object.defineProperty 将原型链上的属性的 configurable 设置为 false，从而实现“不可配置”的效果，并通过实际示例说明该做法的边界与注意点。
需要注意的是，不可配置并不等同于不可写。不可配置的属性仍然可能在某些情况下通过原型链的读取行为被访问，但对其描述符的变更会被阻止，且删除操作通常会失败。
1.2 可配置性在原型链上的影响
原型链上的属性描述符一旦设为不可配置，就会对后续的 redefinition、删除等行为产生约束，从而让依赖该属性的实例行为更加可控。
如果不设为不可配置，那么未来的代码可能通过 Object.defineProperty、delete 以及重新赋值等方式改变该属性的行为，造成难以追踪的副作用。因此，合理选择哪些原型属性应设置为不可配置，是在大型应用中提升稳定性的一种策略。
下面的实战将聚焦一个简单示例，演示如何在自定义构造函数的原型上定义不可配置的属性，以及相关的读写行为与限制。
2. 技术要点与前置条件
2.1 原型链与属性描述符的关系
属性描述符决定了属性的可写性、可枚举性以及可配置性。在原型对象上定义属性时，若将 configurable 设为 false，说明该属性的行为在以后都不可通过重新定义来改变。
通过下面的要点理解实现方式： - 数据属性的值可以通过 writable 控制是否可写 - enumerable 控制是否会在遍历中暴露 - configurable 控制是否可以修改描述符或删除属性
将属性定义在原型对象上，会使通过实例访问该属性时，若属性不存在实例自身的同名属性时，沿原型链查找会返回原型上的值。
2.2 浏览器兼容性与运行时行为
大多数现代浏览器对 Object.defineProperty 的支持良好，但需要注意在某些老旧环境中对原型对象的修改可能会有限制，某些严格模式下的行为也略有差异。
在执行环境中测试是必要步骤，尤其是在涉及不可配置属性的删除与重新定义时，需要捕捉 TypeError 或返回值来判断是否成功。
避免修改全局原型（如 Object.prototype）是一个重要的安全考虑点，实际应用应优先在自定义构造函数的原型上进行不可配置处理。
3. 实战：使用 Object.defineProperty 将 configurable 设置为 false
3.1 基本用法示例
下面的示例中，我们创建一个自定义构造函数，并在其原型上定义一个不可配置的属性。你可以通过读取和修改原型对象中的该属性值来观察行为，但不能通过重新定义来改变其描述符。
// 实战：在自定义原型上定义不可配置的属性
function MyObj() {}// 在原型上定义一个不可配置的属性 'secret'
Object.defineProperty(MyObj.prototype, 'secret', {configurable: false, // 不可配置：无法重新定义、无法删除enumerable: true,writable: true,value: 'top-secret'
});// 演示：读取原型上的属性
const a = new MyObj();
console.log(a.secret); // 输出: top-secret// 修改原型上的属性值（不会伤害描述符，只会改变原型上该属性的值）
MyObj.prototype.secret = 'new-secret';
console.log(a.secret); // 输出: new-secret// 尝试重新定义该属性的描述符，将抛出错误
try {Object.defineProperty(MyObj.prototype, 'secret', {enumerable: false});
} catch (e) {console.log('Cannot redefine property:', e instanceof TypeError); // 通常为 true
}// 删除原型属性，因 configurable 为 false，删除会失败
delete MyObj.prototype.secret;
console.log(MyObj.prototype.secret); // 依然是 'new-secret'// 查看属性描述符，确认 configurable 为 false
console.log(Object.getOwnPropertyDescriptor(MyObj.prototype, 'secret'));
要点总结：通过 Object.defineProperty 将 configurable 设置为 false，使得原型链上的该属性不可重新配置或删除；但在 writable 为 true 的情况下，直接修改原型上的该属性的值仍然有效。
3.2 将属性绑定到自定义原型而非全局原型的做法
出于安全与可维护性考虑，尽量避免直接修改全局原型对象（如 Object.prototype），并偏向于在自定义构造函数的原型上创建不可配置属性。
// 优选做法：仅在自定义原型上定义不可配置属性
function Widget() {}Object.defineProperty(Widget.prototype, 'version', {configurable: false,enumerable: true,writable: true,value: '1.0.0'
});const w = new Widget();
console.log(w.version); // 1.0.0// 尝试删除会失败
delete Widget.prototype.version;
console.log(Widget.prototype.version); // 1.0.0
设计原则：保持对外暴露的 API 稳定性，避免对原生对象进行污染，确保应用行为可预测。
4. 原型链属性不可配置的实际影响
4.1 删除与重新配置的限制
不可配置的属性不能被删除，也不能通过 Object.defineProperty 再次改变描述符。这样的保护在安全域中很有用，能防止意外或恶意代码的干扰。
如果你试图通过 Object.defineProperty 改变一个不可配置属性的配置项，通常会抛出 TypeError。关于示例中的属性，尝试重新定义会被明确捕捉到错误。
删除失败的行为在严格模式与非严格模式下的表现略有差异，但核心点是一致的：不可配置性提供了稳定的属性描述符保护。
4.2 对现有实例的影响
由于属性定义在原型对象上，对通过实例访问时的行为影响来自原型对象，而非实例自身。即使实例没有自己的同名属性，访问也会沿原型链向上查找。
若你在原型上定义不可配置的属性，即使通过实例对该属性赋值，若属性在原型上的 descriptor 是可写的，赋值会改变原型上的值；但重新定义、删除等操作将被阻止。
5. 兼容性与坑点
5.1 现有属性的可变性与潜在风险
对原型链属性设置不可配置需要谨慎，因为它可能影响现有代码的行为与第三方库的兼容性。若某些库依赖于可变的原型属性，强制设置不可配置可能导致难以调试的问题。
在实际生产环境中，建议先进行局部测试与回滚计划，并尽量避免修改全局对象，优先在自定义构造函数的原型上进行不可配置处理。
5.2 调试技巧与测试用例
调试时可以使用 Object.getOwnPropertyDescriptor 来确认属性的 configurable、writable、enumerable 等状态；使用 try-catch 捕获 Object.defineProperty 的异常，以判断属性是否可重新配置。
下面给出一个简单的自测用例，帮助你在无损环境中验证不可配置行为：
function Test() {}
Object.defineProperty(Test.prototype, 'flag', {configurable: false,enumerable: true,writable: true,value: true
});const t = new Test();
console.log(Object.getOwnPropertyDescriptor(Test.prototype, 'flag'));
// 尝试重新配置
try {Object.defineProperty(Test.prototype, 'flag', { writable: false });
} catch (e) {console.log('Rewrite blocked:', e instanceof TypeError);
}
快速检验要点：通过 descriptor、删除操作和重新定义的尝试来验证不可配置性是否生效。
