私有方法必须用private修饰且仅限本类调用；它本质是封装内部逻辑的工具，不参与继承或重写，命名需清晰体现动宾结构，职责单一并可独立测试。
私有方法必须用 private 修饰，且只能在本类中调用
Java 中的私有辅助方法本质就是封装逻辑的“内部工具”，它不对外暴露，也不参与继承或重写。如果你写了 public 或 protected 却想当私有方法用，那只是自欺欺人——其他类真能调，而且 IDE 不会拦你。
实操建议：
-
private是唯一合法选择；default（包级）虽不能跨包调用，但同包下任何类都能碰，不算真正私有 - 不要试图用
final private——private方法天然不可重写，加final多余 - IDEA/Eclipse 在类内 Ctrl+Click 能跳转到私有方法，但外部类看不到声明，也补全不到
辅助方法命名要体现意图，别叫 helper 或 doSomething
私有方法没人强制看文档，名字就是它的接口。叫 validateEmailFormat 比 check 清晰十倍；叫 buildResponseJson 比 process 可读性强得多。名字模糊会导致后续维护者反复点进方法体才能猜用途。
常见错误现象：
立即学习“Java免费学习笔记（深入）”；
- 多个
handleXxx方法堆在一起，看不出分工边界 - 用缩写如
fmtStr，团队新人根本不知道是 format 还是 filter - 名字含动词但没宾语，比如
parse—— parse 什么？JSON？日期？配置？
建议统一用「动词 + 宾语 + 可选上下文」结构，例如：parseUserInputAsInt、trimAndNormalizePhoneNumber。
别把私有方法写成“万能胶”，一个方法只做一件事
辅助方法的核心价值是降低主流程复杂度，不是把所有杂活塞进去。见过把数据库查询、空值校验、日志打印、异常转换全揉进一个 prepareData 里的——这种“辅助方法”比主逻辑还难测、难改、难复用。
使用场景判断要点：
- 这段逻辑是否在当前类里被重复调用 ≥2 次？如果不是，先别急着抽
- 它是否具备明确输入/输出？如果严重依赖成员变量或修改多个状态，说明职责过重
- 能否独立单元测试？如果必须启动 Spring 上下文或 mock 七八个字段，大概率设计偏了
示例：下面这个 calculateDiscount 就太胖了
private BigDecimal calculateDiscount(Order order) {
if (order == null) throw new IllegalArgumentException();
log.info("Start discount calc for {}", order.getId());
BigDecimal base = order.getTotal();
if (base.compareTo(BigDecimal.ZERO) <= 0) return BigDecimal.ZERO;
// …… 还混着促销规则、会员等级、库存校验
}
应该拆成 validateOrderNotNull、getBaseAmount、applyPromotionRule 等更小粒度的方法。
注意构造函数里调用私有方法的风险
在构造函数中调用非 final 私有方法看似安全，但若该类被继承，子类构造器执行前父类构造器已运行——此时子类字段还是默认值（null、0、false），而父类私有方法若间接依赖子类状态（比如通过 this 调用某个被子类重写的非私有方法），就可能出错。
更现实的问题是：构造函数里调用的私有方法，如果抛异常，整个对象实例化失败，且堆栈里看不到业务上下文，排查困难。
实操建议：
- 构造函数里只做最轻量的字段赋值和必要校验（如
Objects.requireNonNull） - 把复杂初始化逻辑移到静态工厂方法里，比如
fromConfig(Config cfg)，这样既能用私有方法，又可控异常传播路径 - 避免在私有方法里访问
this引用的非 final 字段，除非你 100% 确认构造顺序不会导致未初始化访问
真正容易被忽略的是：私有方法不是“绝对安全区”。它不解决线程安全、资源泄漏、空指针这些底层问题，只是把锅从 public 方法里暂时挪了个地方——锅还在，只是盖得严实了点。
