核心是变量应推迟声明、单一职责、就近定义。循环变量写入for内，日志等在首次使用前构造；只用一次的变量内联，需校验或埋点则保留；高频共现字段聚合成结构化类；长流程拆为阶段化方法，入参出参明确。
核心是让每个变量只在真正需要它的地方出现，且只承担单一语义职责。圈复杂度高往往不是逻辑本身多难，而是变量生命周期过长、复用混乱、意图模糊，把控制流“摊平”在几十行里反复修改同一组变量。
推迟声明，让变量“活该出现”的时刻才出生
不要在函数开头堆满String result = ""、List这类占位变量。它们掩盖了真实的数据依赖路径，也延长了变量存活时间，增加误用风险。
- 循环变量必须写在
for语句内，而不是提前声明再赋值 - 日志内容、校验提示、中间转换结果，都在首次使用前一行构造，例如：
String errorMsg = "库存不足，需补货 " + skuId; - 如果某个变量只在
if块中用到，就把它定义在if内部，而非外层作用域
合并冗余链式变量，直连语义终点
当多个变量只是为了一步一跳地传递中间值，而每步都不需单独校验或复用，说明它们割裂了本应连续的语义流。
- 像
String raw = input.trim(); String clean = raw.replaceAll(" +", " "); return clean.toUpperCase();可直接简化为return input.trim().replaceAll(" +", " ").toUpperCase(); - 判断标准很简单：该变量是否被读取两次以上？只用一次，大概率可以内联
- 若某步结果需做空判断、长度校验或记录埋点，则保留为独立变量，此时它已承载明确业务含义（如
isPhoneNumberValid）
用结构化变量替代平行命名，把“散装字段”聚合成上下文
当出现userId、tenantId、traceId、authToken等一组高频共现变量，说明它们天然属于同一个业务上下文片段。
- 新建轻量类（如
ExecutionContext），封装这些字段及基础行为（如isInternalUser()） - 所有方法参数从传5个零散字符串，改为传一个
ExecutionContext对象 - 后续新增字段（如
featureFlags）只需加到该类中，调用方无感知，避免漏传、错序、类型不一致
拆出阶段化方法，用返回值代替隐式状态流转
把原本在一个函数里完成的“加载→校验→转换→落库→通知”流程，按语义边界切分为独立方法，每个方法只接收上一阶段输出，只返回下一阶段所需输入。
- 例如：
loadOrderFromRequest(req)→validateOrder(order)→enrichOrderWithInventory(order) - 每个方法入参精简、出参明确，不再依赖外部变量修改；单元测试可逐段验证，无需模拟整条链路
- 方法名即契约，比如
calculateFinalPriceWithDiscounts()比processPrice()更能约束行为边界
