应立即拆分上千行类，按业务域（如用户注册、密码重置）而非技术层切分；优先剥离高频变更逻辑，封装为接口驱动的独立服务；通过依赖倒置和事件协作解耦，渐进迁移并标记废弃代码。
直接拆，别等“完美时机”。上千行的类已经不是“可维护”级别，而是“随时可能崩坏”的信号。关键不是一步到位，而是按业务边界切出第一批高价值、低耦合的子模块。
先识别业务域，再划职责线
打开这个类，不看代码细节，只扫一眼方法名和字段名。把所有功能点归类到现实业务动作中：比如“用户注册”“密码重置”“邮箱验证”“登录态管理”“第三方授权绑定”——这些不是技术操作，而是用户在系统里完成的一件件事。每个动作背后，都对应一个独立的业务域。不要按技术分层（比如“DAO层”“Service层”），要按用户视角或业务流程来切。
从高频变更点入手，优先拆离易变逻辑
翻 Git 历史，看哪些方法近半年被改过最多次。那些频繁修改的部分，往往就是职责不单一的“重灾区”，比如：
- 订单创建方法里混着库存扣减、优惠券校验、积分发放、短信通知
- 用户更新接口里同时处理头像上传、资料保存、消息推送、行为埋点
这些就是第一批该剥离的对象。把它们各自封装成新类，用明确命名（如 InventoryDeductionService、CouponValidationService），原类只保留协调调用逻辑。
用依赖倒置解耦，避免新旧代码互相牵扯
拆分后，原类不能直接 new 新类，也不能直接访问新类的私有字段。统一通过接口通信：
- 为每个新职责定义清晰接口（如 EmailVerificationService）
- 原类持有接口引用，运行时注入具体实现
- 新类之间不互相调用，只通过事件或回调响应协作（比如注册成功后发事件，由监听器触发邮件发送）
这样后续替换某块逻辑（比如把邮件换为短信）就只需换实现，不影响其他部分。
留好“胶水层”，允许渐进式重构
别指望一次全拆完。保留原类作为入口协调器，逐步把方法迁出。每拆一个职责，就删掉原类里对应的一段逻辑，并加单元测试覆盖迁移路径。过程中可能出现“暂时性重复”，比如新旧两套日志写法并存，没关系——只要新逻辑已上线且稳定，旧逻辑就标记为 @Deprecated，约定下个迭代彻底移除。
