原型不适合存储不变配置数据，因其专为共享方法设计；配置若放原型会导致实例间引用污染、语义错位、工具支持弱，应改用静态属性或模块常量。
原型对象不适合存储不变的配置数据。
为什么原型不是配置数据的合适载体
原型（prototype）是为**共享方法和行为**设计的，不是为存储独立、不可变、实例无关的配置项准备的。把配置放在原型上会带来几个实际问题：
- 所有实例共享同一份引用：如果配置是对象或数组，任一实例修改它，其他实例立刻受影响；即使你本意是“只读”，JavaScript 无法靠原型机制强制保护
- 语义错位：配置数据属于类/模块的静态元信息，和“某个实例该怎么做”没有关系，放在 prototype 上违背面向对象中“原型描述行为”的约定
- 可读性与工具支持弱：IDE、TypeScript、JSDoc 难以准确推导原型上的“配置属性”，容易误判为方法或实例属性
推荐方式：用静态属性或模块级常量
真正不变的配置，应定义在构造函数本身（静态属性）或模块顶层，明确表达其“类级别”“一次性定义”的本质：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
-
构造函数静态属性：
MyClass.API_BASE = 'https://api.example.com';—— 直观、易访问、符合 ES6+ 类语法习惯（static API_BASE = '...'） -
模块常量（推荐）：在单独的
config.js中导出export const TIMEOUT_MS = 5000;，按需导入 —— 解耦、可复用、支持 tree-shaking -
Symbol 做私有键（进阶）：若必须绑定到类但又不想暴露，可用
const CONFIG = Symbol('config');在类内部定义静态私有配置对象
如果硬要用原型，至少做防御处理
极少数场景（如兼容老旧代码）需要把配置挂原型上，务必冻结对象防止意外修改：
立即学习“Java免费学习笔记（深入）”；
- 用
Object.freeze()封装原始值或简单对象：MyClass.prototype.config = Object.freeze({ version: '1.2.0', debug: false }); - 避免直接赋值可变结构：
MyClass.prototype.endpoints = { user: '/v1/users' };❌（未冻结，可被改） - 不依赖原型链查找配置：显式通过
MyClass.prototype.config访问，而非this.config（否则可能被实例属性遮蔽）
配置数据的本质是“声明即确定”，原型的本质是“动态共享行为”。两者目标不同，混用反而增加维护成本。选对位置，比技巧更重要。
