单一职责的判断标准是看每个public方法是否服务于同一业务概念如果方法变化的原因不同(如sendemail和generatereport)则违反了这一原则应通过委托、界面抽象等方式安全拆分并确保测试重点关注单一职责。如何判断单一职责是否“做太多事”看每个类别public是否所有的方法都服务于相同的业务概念。例如UserManager里既有saveUser()、sendEmail()又夹着generateReport()那么它很有可能违反单一职责——sendEmail()和generateReport()变化的原因完全不同。实操建议立即学习“Java免费学习笔记(深入)每次新增一个public方法前先问:如果这个逻辑改为通知方式(比如从邮件改为短信)或者改为报表格式PDF → Excel你想改变这个类别吗如果答案是“是”应该拆除。将日志、验证、序列化等一般行为分为独立类别或注释不要让业务类自己log.info()或new ObjectMapper()。IDE 中右键类 → “Find Usages观察调用方的分布如果UserService被 Web 三个调用层、定时任务和消息监听器但每个地方只使用 1–2 一种方法说明它实际上承担了多个角色。重建过程中如何安全拆分UserManager不要一上来就删除方法而是先隔离依赖然后迁移行为。重点不是“如何拆除”而是“如何防止调用人感知变化”。实操建议立即学习“Java免费学习笔记(深入)新建EmailSender类把原UserManager.sendEmail()搬过去保留原方法作为委托:public void sendEmail(User user) { emailSender.send(user); }—— 调用方不需要改变但你有一个可测试和可替换的边界。单独提出数据库操作UserRepository用接口定义UserRepository实现类叫JpaUserRepository。以这种方式取代未来 Redis 或 Feign 调用只改变实现不触及业务逻辑。避免“拆卸和拆卸成一堆”xxxHelper”Helper 职责往往模糊命名要体现能力比如PasswordEncoder、UserValidator而不是UserHelper。为什么Transactional放错位置会使内聚失效把Transactional加在UserManager.updateProfile()这似乎很方便但它将数据一致性、重新测试逻辑和交易传播行为耦合到业务方法的签名中。因此该方法不仅需要业务判断还需要管理底层资源控制。实操建议立即学习“Java免费学习笔记(深入)事务边界应由最外层协调员控制例如 Controller 或 Service 安排层。业务类UserProfileService只负责“更新头像URL”和“验证昵称长度”不声明事务。如果必须在 service 层启事务采用专门的安排类别如UserProfileUpdateOrchestrator里面组合UserProfileService和NotificationService并将其添加到方法中Transactional。注意 Spring 代理限制类似的中国方法 A 调用此类皮带Transactional方法 B事情不起作用。这种写法本身就是高耦合信号必须拆除。测试不能写下来吗职责往往不干净当你发现单元测试需要测试时 mock 数据库、邮件客户端、第三方 API 才能跑通UserManager.testSaveAndNotify()说明这一类同时承担了领域逻辑、基础设施适应、流程安排三重责任。实操建议立即学习“Java免费学习笔记(深入)每个被测类只依赖接口不超过 3 一个。超越意味着它在协调太多的东西应该拆除。将所有依赖注入构造函数拒绝static工具类或ApplicationContext.getBean()—— 后者会让你在测试中根本无法替换行为。测试命名暴露职责不是testUserManager()而是shouldSendWelcomeEmailWhenUserIsCreated()对应EmailSender类shouldRejectNickNameWithSpecialChars()对应UserValidator。真正困难的不是分类而是识别哪些逻辑“看起来相关但实际上原因不同”。例如用户在注册时发送短信和编写操作日志都发生在同一时间点但短信频道可能会在下周更换供应商而日志格式可能会在下季度进行调整——他们不应该呆在同一类别中。