单一职责原则的核心是“变化原因唯一”，而非功能数量多少；一个类应仅因一个理由被修改，职责即变化的动因，需依变更场景（如权限规则、日志格式、注册流程）判断是否混杂，接口与实现均须职责一致，但无独立变化迹象时不必过度拆分。
单一职责原则（SRP）在类功能划分中的界定标准，核心不在于“功能数量多少”，而在于“变化原因是否唯一”。一个类是否符合SRP，关键看：当需求或环境发生变化时，有没有且仅有一个理由需要修改它。
职责 = 变化的原因，不是功能的罗列
比如一个 UserManager 类包含创建用户、校验权限、写操作日志三个方法。表面看是三件事，但需追问：
- 如果权限规则调整（如从角色制改为RBAC），哪些方法要改？——只有校验逻辑
- 如果日志格式升级（如增加traceId字段），哪些方法要改？——只有日志写入部分
- 如果用户注册流程新增实名认证步骤，哪些方法要改？——主要是创建逻辑
三类修改动因彼此独立，说明这三个功能属于三个不同职责轴，不应共存于同一个类中。
判断是否该拆分的实操信号
以下情况强烈提示职责混杂，需考虑分离：
- 类中出现明显不同领域的名词：如同时含 “log”、“auth”、“export”、“notify” 等前缀的方法
- 不同方法由不同团队维护或按不同节奏迭代（如日志模块每季度升级，用户主流程每月发版）
- 单元测试用例明显分组：一组测业务逻辑，一组测格式转换，一组测外部调用
- 添加新功能时，常需在多个已有方法里插入相似代码（如每次都要加埋点或审计日志）
接口与实现层的职责一致性
SRP 不只约束类，也约束接口定义。例如：
❌ 违反 SRP 的接口：
public interface UserService {
void createUser(User user);
List<String> getUserLogs(Long userId); // 日志职责侵入
void sendWelcomeEmail(Long userId); // 通知职责侵入
}
✅ 合理拆分后：
public interface UserService { void createUser(User user); }
public interface UserLogService { List<String> getUserLogs(Long userId); }
public interface UserNotificationService { void sendWelcomeEmail(Long userId); }
接口层面职责清晰，实现类才能真正专注一件事。
不必过度拆分的边界条件
SRP 不是越细越好。以下情形可保留在同一类中：
- 两个行为始终同步变更（如用户 id 和 username 字段永远由同一份业务规则约束）
- 技术约束使分离成本远高于收益（如硬件驱动中连接控制与数据收发物理上无法解耦）
- 当前无任何迹象表明二者会独立变化（没有历史变更记录，也没有明确的演进路线图）
此时强行拆分反而引入不必要的抽象和间接层。
