应将共享方法和只读属性放在构造函数的prototype上，实例独有属性在构造函数内用this定义，可变共享状态则通过构造函数静态属性或闭包管理，避免prototype上出现可变引用类型导致意外共享。
用原型链解决属性共享问题，核心是把多个实例共用的数据或方法放在构造函数的 prototype 上，而不是在构造函数内部用 this 重复定义。这样既节省内存，又能保证所有实例访问的是同一份逻辑或默认值。
为什么实例内定义属性会导致共享问题？
如果在构造函数里直接给 this 赋值一个引用类型（比如数组、对象），每个实例都会拥有独立副本——看似“不共享”，但容易误以为该属性是“类级别”的；而如果本意是让所有实例共用某个默认配置或工具方法，却写在实例上，就白白浪费内存，且修改无法同步。
更典型的问题是：本想让所有实例共享一个计数器、缓存对象或工具函数，却因写在构造函数里，导致每个实例都新建一份，失去共享意义。
把共享数据/方法挂到 prototype 上
把应该被所有实例共用的内容，统一放到构造函数的 prototype 属性中：
- 方法一律定义在
prototype上（这是最佳实践，避免每次新建实例都重复创建函数） - 只读的默认配置、常量、工具对象（如
{ apiRoot: '/v1' }）也可放这里 - 避免在 prototype 上放可变的引用类型（如空数组、空对象）作为实例状态容器——否则所有实例会意外共享同一份数据，引发 bug
✅ 正确示例：
function User(name) {
this.name = name; // 实例独有
}
User.prototype.sayHello = function() {
return `Hello, ${this.name}`;
};
User.prototype.version = '1.2'; // 只读常量，安全
User.prototype.config = { timeout: 5000 }; // 安全：只读配置，不修改
需要“共享但可修改”的状态？用静态属性或闭包管理
如果真需要跨实例共享并可修改的状态（如全局请求计数器、主题模式），不要放在 prototype 上，因为 prototype 是为实例服务的，不是为类设计的“静态作用域”。
- 推荐方式：直接挂在构造函数本身（即“静态属性”）
- 例如：
User.requestCount = 0;，然后在方法中通过User.requestCount++操作 - 或者用模块级变量 + 闭包封装，更可控
❌ 错误示例（陷阱）：
User.prototype.cache = {}; // 所有实例共享这个对象！
User.prototype.items = []; // 所有实例共享这个数组！
一旦某个实例执行 user1.items.push('a')，user2.items 也会看到 'a' ——这不是“共享功能”，而是 bug。
检查属性来源：hasOwnProperty vs in
判断一个属性是实例自有还是来自原型链，可用：
-
obj.hasOwnProperty('prop')→ 只返回true当属性在实例自身上（非继承） -
'prop' in obj→ 返回true如果属性存在于实例或其任意原型上
这在调试共享行为、实现深拷贝或属性遍历时很关键。
不复杂但容易忽略：共享靠 prototype，状态隔离靠实例，跨实例状态靠构造函数自身或外部模块。分清这三层，属性归属就不再混乱。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
