方法体本身不直接符合单一职责原则，但它是判断类是否遵守srp的直观窗口；方法体若混入多类关注点（如校验+db操作、计算+第三方调用等）即违背srp；理想方法应只做一件可命名、可替换的事，避免“and/with/then”式命名；通用逻辑（日志、序列化等）须抽离至aop、工具类或独立组件。
方法体本身不直接“符合”单一职责原则（SRP），因为 SRP 是针对类提出的——它要求一个类只有一个引起它变化的原因。但方法体的编写方式，恰恰是判断一个类是否真正遵守 SRP 的最直观窗口。换句话说：方法体写得“杂”，往往意味着所在类已经违背了单一职责。
看方法体是否混入多类关注点
一个方法体内如果同时出现以下任意组合，大概率说明它承载了多个职责：
- 参数校验逻辑 + 数据库操作（如
if (user == null) throw ...紧接着jdbcTemplate.update(...)） - 业务计算 + 第三方调用（如算完积分后直接
restTemplate.postForObject(...)发通知） - 数据持久化 + 缓存更新 + 日志记录（三者挤在同一个
updateUser()方法里） - 序列化操作（
new ObjectMapper().writeValueAsString(...)）和核心业务逻辑耦合
方法体应只做一件事，并且这件事要可命名、可替换
理想的方法体，应该能用一个清晰动词短语概括其全部行为，比如：
-
validateUserProfile()—— 只校验，不查库、不发消息 -
persistUserProfileToMySQL()—— 只执行 SQL 插入或更新，不校验、不缓存 -
sendSmsNotification()—— 只调短信网关，不构造内容逻辑（内容由上游传入）
如果方法名需要加 “And”、“With”、“Then”（如 updateUserAndSendEmail()），基本就是警报信号。
把通用逻辑从方法体中“请出去”
日志、异常包装、事务控制、参数转换等非核心业务逻辑，不应硬编码在业务方法体内：
- 避免在方法开头写
log.info("start updateUser")；改用 AOP 或统一拦截器 - 避免手动 new
ObjectMapper或DateTimeFormatter；抽成独立工具类或注入 Bean - 校验规则不要散落在各个方法里；提取为
UserValidator类，方法体只调validator.validate(user)
重构方法体时优先保留契约，再分离实现
不要一删了之。安全的做法是：
- 新建职责明确的类（如
EmailSender、UserRepository） - 把原方法体中对应逻辑完整搬过去
- 原方法改为委托调用：
emailSender.send(user) - 保持方法签名不变，调用方无需修改
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
