变量命名需体现类型、角色与上下文，如paymentEvent而非item；分阶段命名流处理链（rawOrders→validatedOrders）；Lambda参数显式命名，避免模糊方法引用；日志与调试须输出真实类型及样本。
避免在排查多态流数据时因变量命名混乱找不到具体组件，核心是让变量名本身成为可读、可搜、可追溯的线索，而不是靠猜或翻源码。重点不在“写得快”，而在“看得清、查得准、改得稳”。
变量名必须携带类型+角色+上下文
流式处理中常见如 stream.map(...)、filter(...) 等链路，若中间变量命名为 item、obj、data，等于主动放弃调试线索。
- ✅ 推荐写法：
paymentEvent、pendingOrder、legacyUserDto——一眼看出来源、状态和语义 - ❌ 避免写法：
temp、res、item（无上下文）、u（缩写不可读） - 对泛型流尤其关键：比如
Stream<Order>的中间变量不要叫e，而应叫order或currentOrder；若做过滤转换，可用shippedOrder、nonExpiredOrder显式体现逻辑
流操作链中禁止复用同名变量覆盖
一段流处理常经历 map → filter → flatMap 多个阶段，若全程只用一个变量名（如反复赋值给 orders），会丢失各阶段的数据形态差异，导致日志或断点无法区分“这是过滤前还是转换后”。
- ✅ 分阶段命名：
rawOrders→validatedOrders→enrichedOrders→dispatchableOrders - ✅ 利用 IDE 提示：IntelliJ 在 Stream 链上悬停可看当前阶段类型，但前提是变量/方法引用有明确语义；匿名 Lambda 中用
o -> ...不如order -> ...可读 - ⚠️ 特别注意 collect 后结果：不要统一叫
result，而应叫userOrderSummaryMap、skuStockStatusList等带业务含义的名称
方法引用与 Lambda 必须自解释，不依赖外部作用域
当使用 orders.stream().map(User::toDto) 或 .filter(this::isEligible) 时，如果 User 类有多个 toDto() 方法，或 isEligible() 逻辑随字段变更而隐性变化，变量名再清楚也救不了。
- ✅ 把隐式绑定转为显式表达：
.map(u -> UserDto.from(u, clock.now()))，把时间戳等上下文固化 - ✅ 方法引用仅用于无参、确定、稳定的方法；含条件或依赖外部状态的逻辑，一律展开为 Lambda 并命名关键参数
- ✅ 对复杂判断，封装成静态工具方法并用语义化名：
.filter(OrderFilters::isNotCancelledOrRefunded)，比this::check清晰十倍
日志与调试点强制输出变量真实类型
流是延迟执行的，IDE 调试器可能只显示 ReferencePipeline$3@xxxx，看不出里面是什么。不能只打 log.info("orders: {}", orders)。
- ✅ 日志中加类型标识：
log.debug("validatedOrders ({} items): {}", validatedOrders.size(), validatedOrders.getClass().getSimpleName()) - ✅ 关键节点打印首条样本：
validatedOrders.findFirst().ifPresent(v -> log.trace("sample: {}", v)) - ✅ 断点处用 IDEA “Evaluate Expression” 直接输入
validatedOrders.iterator().next().getClass()，快速确认实际类型
