可读性差的根源不在__proto__，而在原型链设计本身。__proto__仅是访问接口，真正影响可读性的是职责清晰度、命名准确性与行为可预期性；应优先采用组合式结构与显式模块挂载替代隐式原型查找。
__proto__ 本身不提升可读性，反而容易掩盖设计意图。它只是暴露原型链的一层访问接口，不是为“理解复杂链”而存在——真正影响可读性的，是链上每一层的职责是否清晰、命名是否准确、行为是否可预期。
__proto__ 让人误以为“看到就是理解”
在控制台输入 obj.__proto__ 能展开一层原型，再点一次又一层……但这种逐级点击的操作，容易让人陷入“技术路径迷宫”，忽略业务逻辑归属：
- 看到
obj.__proto__.__proto__.validate，并不知道这个validate是表单校验、还是权限检查、还是第三方 SDK 注入的副作用 - 无法区分哪些方法来自基类、哪些来自 mixin、哪些是临时打补丁加上的
- 没有上下文注释时，新人可能花半小时才搞清
getDisplayName()其实定义在第三层原型的UserMixin里
用显式结构替代隐式查找
与其依赖 __proto__ 拼凑继承关系，不如让代码自己“说出它由什么组成”：
- 把能力拆成独立模块，挂载为实例属性：
this.formatter = new DateFormatter()，调用时直接this.formatter.format() - 使用组合式类声明：
class User extends WithAuth.with(WithEvents).with(Validatable)（借助工厂函数或装饰器） - 构造函数上方加简短说明：
// 组合了 AuthBehavior（登录态管理）和 Cacheable（本地缓存策略）
调试时 __proto__ 有用，但不能代替设计文档
开发阶段确实可以靠 console.dir(obj) 或逐层 __proto__ 查看继承结构，但它只是辅助工具：
- 浏览器控制台显示的原型链，不包含动态注入的代理逻辑或 WeakMap 私有行为
- Vue/React 的响应式代理会拦截
__proto__访问，导致显示结果失真 - 真正需要协作时，靠的是 README、JSDoc 注释、或类型定义（如 TypeScript 接口），而不是翻原型链
可读性差的根源不在 __proto__，而在链本身的设计
当一个对象要经过 4 层原型才能拿到 save() 方法，问题不是 __proto__ 难读，而是：
- 没人能一眼看出
save属于数据持久化职责，还是网络请求封装，还是事务包装 - 修改某一层原型，可能意外影响其他看似无关的子类
- 单元测试中 mock
save时，得先确认它在哪一层，再决定 patch 哪个 prototype
把 save 明确放在 this.persistence 下，比让它藏在第 3 层原型里，自然得多。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
