应拆分职责混杂的变量，即同一变量在同作用域内多次赋值且含义不同，如result既存查询结果又存响应体；拆分需按逻辑阶段、生成方和用途界定边界，并配合类拆分治本。

当一个类里堆了太多变量，尤其是一些用途模糊、反复复用的临时值，它就不再是“对象”，而成了“变量仓库”。拆分变量（Split Variable）不是简单地多起几个名字，而是把混在一起的责任切开，让每个变量只说一件事。

识别该拆的变量：看它有没有“变脸”

一个变量如果在同一个作用域内被多次赋值，且每次代表不同含义，就是典型的拆分信号。比如：

• 先存面积，再存折扣后总价
• 先表示初始加速度，又覆盖成合力加速度
• 一个result既接数据库查询结果，又接HTTP响应体，还临时存校验错误信息

这类变量不是“暂存”，而是“兼职”——它越忙，代码越难懂。

拆分的关键不在数量，在职责边界

不要为了拆而拆。重点是问：这个值在逻辑上属于哪个阶段？由谁负责生成？下游用它来做什么？

• 面积（area）和最终价格（total）属于不同计算阶段，应分属不同变量
• 初始加速度（primaryAcc）和二次受力后的加速度（secondaryAcc）驱动不同物理过程，不能共用一个标识符
• 如果一个类里同时有orderStatus、lastNotificationTime、cachedInventoryCount，它们更新时机、来源、用途全不相同，就说明这个类正在悄悄承担状态管理、通知调度、缓存同步三重职责

配合类拆分，效果才真正落地

单靠变量命名改善，治标不治本。当变量群体现明显分组特征时，就是类该拆的信号：

• 某些变量总是一起被读写（如discountRate、promoCode、isEligible），说明它们属于定价规则子领域
• 另一些变量只在发邮件前后出现（如emailTemplateId、recipientList、sendAt），就该归入通知模块
• 构造函数里注入了支付网关、库存客户端、日志服务——这不是依赖多，是职责乱；该按变化原因，拆成OrderPricingEngine、InventoryCoordinator、AuditLogger

别踩这些坑

拆分变量容易，拆得干净不容易：

• 避免用temp1、temp2这类无意义命名，新变量名必须能回答“它为什么存在”
• 不拆循环计数器或迭代索引（如i、j），那是语言惯用法，不是坏味道
• 如果变量只被赋值一次、用途始终如一，强行拆分反而增加认知负担
• 拆完变量后，若发现仍有大量字段彼此无关，就要立刻转向类级重构——变量是症状，类才是病灶