直接抽取重复逻辑为私有方法是最简单有效的去重手段，关键在于准确识别语义明确、参数可控、无外部依赖且多处出现的可复用单元，并遵循命名清晰、参数内聚、边界明确的设计原则。
直接把重复逻辑抽成私有方法，是最简单也最有效的去重手段。关键不在“能不能抽”，而在于“抽得准不准”——要识别真正可复用的语义单元，而不是机械地剪切粘贴。
识别可提取的重复片段
不是所有重复都值得提取。优先关注那些：语义明确、参数可控、不依赖外部状态、在多个公有方法中出现超过一次的逻辑块。比如字符串解析中的数字过滤、DTO转换中的字段映射、校验逻辑中的正则匹配等。
- 同一段 Stream 链（如
.filter(...).map(...).collect(...)）在两个以上方法里一模一样 - 多处出现相同的 null 判断 + 默认值赋值组合
- 对某个对象字段做相同转换（如时间戳转 LocalDateTime、ID 转字符串列表）
- 重复的异常包装逻辑，比如统一将 SQLException 转为自定义 ServiceException
设计私有方法的三个要点
抽出来的方法不是越短越好，而是要具备清晰职责和稳定契约。
-
命名体现意图：不用
helper1()或process()，而用extractNumericTokens()、toRoleIdsList()、isValidEmailFormat() -
参数精简且内聚：只传必要输入，避免塞一堆无关字段；若需多个参数，考虑封装为参数对象（如
ParseConfig） - 不破坏原有边界：私有方法内部不访问类成员变量（除非该变量是其逻辑必需的状态），优先通过参数传递数据，保持可测试性和无副作用
处理 Stream 中的重复操作
Stream 链特别容易重复，但直接提取成私有方法时要注意返回类型和链式兼容性。
立即学习“Java免费学习笔记（深入）”；
- 如果重复的是整个流处理结果（如最终的
List<String>），就让私有方法返回该结果类型 - 如果只是中间操作（如过滤非数字字符），可返回
Predicate<String>或Function<String, Integer>，便于在不同流中复用 - 避免在私有方法里调用
.collect()—— 留给调用方决定终端操作，提高灵活性 - 示例：
private static Predicate<String> isNumericToken() { return s -> NUMBER_PATTERN.matcher(s).matches(); }，然后在各处用.filter(isNumericToken())
警惕“伪重复”和过度拆分
有些看似重复的代码，实际语义或上下文不同，强行合并反而降低可读性。
- 两个 if 块都写了
if (obj != null)，但后续处理完全不同 → 不应合并 - 同样调用
userRepository.findById()，但一个用于校验存在性，一个用于加载完整实体 → 分开更清晰 - 方法拆得太碎（如每个 map 操作都单独提），会让主流程像拼图，增加理解成本
- 判断标准：抽完之后，原方法是否更易读懂？新私有方法是否能在别处自然复用？
