React类组件中private关键字的最佳使用实践是什么

这种写法的设计思路 #

这是团队落地TypeScript封装约束时非常典型的规则误用，出发点本身是做访问边界收敛：
TS的private修饰符作用是编译阶段的类型检查，被标记的类成员不允许在类外部通过实例访问，也不允许子类直接访问。不少团队刚从JS切换到TS时，很容易定出“所有类方法默认加private”的一刀切规则，初衷是强制组件封装，避免外部代码（比如父组件通过ref取实例、其他耦合的业务逻辑）随意依赖组件内部实现，把组件的对外接口收敛到props和少数明确设计的公开实例方法上，降低后续重构的破坏性变更风险。
但这个写法完全没区分方法的实际调用方：React生命周期方法的调用主体是React框架本身，TS的private只是编译时的类型约束，运行时不会阻止React调用这些方法，所以加了private也不会影响生命周期正常执行，但会平白引入额外问题。

生命周期方法的公共调用场景 #

首先明确：业务代码中不存在任何合理场景需要主动调用组件的生命周期方法，所有主动调用生命周期的写法都是违反React设计规范的反模式。
只有两类非业务场景会触发生命周期方法的调用：

• 框架内部调度：React的渲染、更新、卸载流程会自动按时机调用对应生命周期，这是框架的内部逻辑，不属于业务层面的公共API调用。
• 组件继承场景：如果通过类继承抽离公共逻辑（比如自定义业务组件基类、基于类继承实现高阶组件），子类重写生命周期方法时，通常需要调用super.xxx()执行父类的生命周期逻辑。这时候如果父类把生命周期标了private，TS会直接抛出类型错误阻止super调用，这也是无脑给生命周期加private最常见的坑。
  至于通过ref拿到组件实例后强行调用生命周期的写法，本身就应该被禁止，哪怕运行时能绕过TS检查执行，也属于强耦合内部实现的坏代码。

private关键字的标准最佳实践 #

• 按访问边界精准标记，拒绝一刀切规则：写类方法时先明确它的使用范围，只有确定只在当前类内部使用、不需要给子类、外部实例访问的方法（比如内部工具函数、不对外暴露的状态计算逻辑、内部事件处理方法），才标记为private，不要为了格式整齐给所有方法无脑加。
• 特殊方法不要乱加private：React的各类生命周期方法、组件明确设计给外部通过ref调用的公开实例方法，都不要加private——前者需要支持子类的super调用，后者本身就是对外暴露的接口，加private只会导致类型校验报错，起不到任何封装作用。
• 区分不同访问控制的适用场景：
  • 只允许类内部访问、连子类都不允许触碰的核心内部逻辑，优先用ES原生的#开头私有字段，这是JS运行时层面的真私有，比TS仅做编译时检查的private安全性更高。
  • 允许子类访问、不允许外部实例访问的复用逻辑，标记为protected，非常适合抽公共基类时给子类复用的通用逻辑。
  • 明确设计给外部调用的公开方法，不需要额外加修饰符，TS中类方法默认就是public权限。
• 不要让类型约束反过来破坏代码逻辑：访问修饰符的作用是帮你明确边界、减少错误，如果为了满足死板的格式规则加private，导致继承、框架调用出现类型错误，反而违背了用TS的初衷。

内容的提问来源于stack exchange，提问作者John McGellan