“禁止修改原生原型”的工程禁令体现为lint配置中的freeze规则或no-extend-native、脚本加载时优先冻结原生原型、以及协作中因原型污染导致的隐性维护成本上升。
识别“禁止修改原生原型”的工程禁令，关键不在于找一句口号式的规则，而在于发现它在代码规范、工具链和团队实践中的具体落点。这类禁令本质是防御性工程决策，目的是守住 javascript 运行时最底层的确定性。
从静态检查配置中直接识别
该禁令最明确的信号出现在项目使用的 Lint 工具配置里。例如，在 bootstrap-datepicker 项目的 .jshintrc 中明确启用了：
-
"freeze": true —— JSHint 会直接报错任何对
Array.prototype、Object.prototype等原生构造器原型的赋值或定义操作 - 配合 "undef": true 和 "eqeqeq": true 等规则，形成对基础运行环境完整性的联合约束
只要项目根目录存在启用 freeze 的 JSHint 或 ESLint（如 no-extend-native 规则），就代表这条禁令已进入工程强制环节，不是建议，而是构建失败的红线。
从脚本加载顺序与执行时机反推
当代码中出现类似以下逻辑，说明团队已意识到风险并主动设防：
- 在所有第三方脚本之前，第一时间执行
Object.freeze(Array.prototype)等冻结操作 - 使用 IIFE 封装核心模块，避免原型污染穿透到业务层
- 在模块入口处校验关键方法是否被篡改，例如：
if (String.prototype.trim !== nativeTrim) throw new Error("Native prototype tampered")
这类代码不是“写了就好”，而是必须早于任何外部依赖执行——它的存在本身，就是对禁令落地可行性的验证。
从协作场景中感知维护性风险
禁令一旦松动，风险不会立刻爆炸，而是以隐蔽方式侵蚀长期可维护性：
- 不同模块各自 patch 同一个原型（比如都重写
Array.prototype.flatten），导致行为不一致，调试时难以定位源头 - 升级某个依赖后，其内部开始使用新标准 API（如
Array.from），但被冻结的原型让 polyfill 失效，引发兼容性断裂 - 新人不了解约定，为图方便在 utils 文件里写
String.prototype.toTitleCase = ...，后续多人复用该文件，污染扩散到整个应用
这些不是单次 bug，而是会让每次重构、升级、排查都多一层不确定性，最终抬高整个代码库的理解与协作成本。
真正起作用的禁令，从来不在文档里，而在编辑器报错、CI 构建失败、以及老手看到 Boolean.prototype.toString 被赋值时下意识皱起的眉头中。
