final修饰局部变量本质是强制“只赋值一次”，从编译期杜绝修改，保障结算数据安全；需明确初始化时机、区分基本类型与引用类型的只读性、配合不可变容器、支持Lambda安全捕获，并通过语义化命名强化只读意图。
用 final 修饰局部变量，本质是让变量在方法作用域内“只赋值一次”，从而从编译期就切断修改路径——这正是保障结算数据不被意外篡改的第一道硬性防线。
明确初始化时机，杜绝未赋值或多次赋值
结算逻辑中涉及的关键中间值（如折扣率、税费基数、实付金额等）必须在声明时或首次使用前完成唯一赋值：
- 支持两种写法：声明即初始化（final BigDecimal discount = calculateDiscount(order);），或延迟到计算后立即赋值（final BigDecimal amount; amount = order.getTotal().multiply(rate);）
- 二者只能选其一；若声明后未赋值就参与运算，编译报错；若尝试二次赋值（如再写 amount = ...），同样编译失败
- 避免在 if/else 多分支中遗漏赋值——所有可能路径都必须确保该 final 变量被且仅被赋值一次
区分基本类型与引用类型，防止“伪只读”陷阱
结算数据多为数值型（BigDecimal、int、double），属基本语义只读；但若用到集合类（如临时汇总的费用明细列表），需特别注意：
-
final List
items = new ArrayList(); → 引用不可变，但 items.add(...) 合法，内容仍可变 - 真正需要只读，应配合不可变包装：final List
items = List.copyOf(rawItems); （Java 10+）或 Collections.unmodifiableList(new ArrayList(rawItems)); - 优先选用不可变容器（如 List.of()、Map.ofEntries()）直接构造，从源头杜绝修改可能
配合 Lambda 和匿名内部类，守住闭包安全边界
结算过程常嵌套异步处理或回调（如日志记录、风控校验），此时 final 局部变量可被安全捕获：
- 未加 final 的局部变量在 Lambda 中访问会触发“effectively final”检查；显式声明 final，语义更清晰，也避免因后续代码改动（如中途重新赋值）导致编译失败
- 例如：final BigDecimal finalAmount = amount; executor.submit(() -> audit.log("settle", finalAmount));
- 这种写法不仅通过编译，还向协作者明确传递“此值已锁定，不可再动”的意图
结合业务语义命名，让只读意图一目了然
变量名本身是代码文档的一部分。结算场景下，推荐采用带语义前缀或全大写风格：
- 基础数值：final BigDecimal SETTLED_TOTAL;、final int MAX_REFUND_DAYS;
- 复合结构：final SettlementContext context;（前提是 SettlementContext 本身是不可变类）
- 避免模糊命名如 final BigDecimal temp; 或 final Object data; —— 名称不体现只读性，也掩盖业务含义
