构造函数中应按需绑定箭头函数，仅对需外传且单独调用的回调（如事件处理器、定时器）绑定；内部方法应定义在原型上以节省内存、利于继承和维护。
构造函数里不该把所有方法都写成箭头函数赋值，关键在于“按需绑定”，不是“一锅端”。盲目滥用会增加实例内存开销、掩盖设计意图，还可能干扰调试和继承逻辑。
只对需要外传的回调方法用箭头函数
真正需要锁定 this 的，是那些会被提取后单独调用的函数，比如事件处理器、定时器回调、Promise 链中的 .then() 参数等。其他仅在类内部调用的方法（如 validate()、formatData()）完全可以用普通方法定义，走原型链更轻量。
- ✅ 推荐：在 constructor 中只绑定 this.handleClick = () => { ... } 这类明确要传给 addEventListener 或 setTimeout 的方法
- ❌ 避免：把 this.calculateTotal = () => { ... } 也写进 constructor——它只在类内被 this.calculateTotal() 调用，没必要实例化一份
警惕类字段语法带来的隐式绑定
像 handleClick = () => {} 这种类字段写法，看似简洁，实则每次创建实例时都会生成新函数对象，且依赖转译（如 Babel），在不支持该语法的环境会直接报错。它绕过了构造函数的显式控制，也难以统一做性能或日志拦截。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- ✅ 更稳妥：坚持在 constructor 内手动赋值，逻辑集中、行为可预期
- ❌ 慎用：类字段箭头函数，尤其在工具库、基础组件或需长期维护的模块中
注意继承场景下的 this 指向一致性
子类继承父类后，如果父类在 constructor 中用箭头函数绑定了某个方法，该方法里的 this 仍指向子类实例（因为箭头函数捕获的是运行时的实例）。这本身没问题，但若子类重写了同名普通方法，而外部又混用两种写法，容易造成行为不一致。
立即学习“Java免费学习笔记（深入）”；
- ✅ 建议：父子类中同类用途的方法保持统一风格——要么都走原型方法（供继承覆盖），要么都走 constructor 绑定（强调不可覆盖）
- ❌ 避免：父类绑定 this.submit，子类却定义 submit() {}，导致调用方无法分辨实际执行的是哪个
别用箭头函数替代构造逻辑
构造函数的核心职责是初始化状态和建立实例关系。如果在 constructor 里大量使用箭头函数封装业务逻辑（比如 this.apiCall = () => fetch(...)），会让构造过程变得臃肿，也违背单一职责原则。
- ✅ 正确做法：构造函数只做必要初始化；API 请求等逻辑封装为普通方法，需要时再绑定
- ❌ 错误倾向：把整个业务流程塞进 constructor 的箭头函数里，既难测试，也不利于后续扩展
