final参数只防止变量重赋值，不阻止对象内容修改、不提供线程安全、不替代空检；其真正价值是设计信号与防错提示，而非安全机制。
Java 中的值传递机制本身不提供安全性，final 关键字也不能改变“传的是引用副本”这一本质。二者结合，**无法确保对象内容安全，只能防止参数变量被意外重赋值**——这是常见误解的根源。
值传递 + final 参数：只锁住“变量名”，不锁住“对象”
Java 所有参数都是值传递：基本类型传值，引用类型传的是对象地址的副本。final 修饰参数后：
- 对基本类型（如 int、boolean）：确实阻止了方法内重新赋值，比如 final int x = 5; x = 10; 编译报错
- 对引用类型（如 final List
）：只禁止写 list = new ArrayList(); 或 list = null;，但 list.add("a")、list.clear() 全部合法且生效
为什么这不能带来“安全”？
所谓“安全”，常指防误改、防并发污染、防输入破坏。但 final 参数对此无能为力：
- 它不阻止对象内部状态变更 —— StringBuilder.append()、ArrayList.set() 照常运行
- 它不提供线程安全 —— 多个线程同时调用含 final 参数的方法，仍可能竞争修改同一个可变对象
- 它不替代空值校验或边界检查 —— final String s 仍可能是 null，不加判空就调用 s.length() 会 NPE
真正需要“安全”的场景，该怎么做？
靠 final 参数不行，得换思路：
- 传不可变对象：优先用 String、Integer、ImmutableList.of()（Guava）、List.copyOf()（JDK 10+）
- 做防御性拷贝：接收可变集合时，自己创建新副本，如 new ArrayList(input) 或 Collections.unmodifiableList(input)
- 明确契约约束：在 Javadoc 中写清“本方法不修改入参”，配合静态检查工具（如 ErrorProne）识别可疑修改
- 用注解辅助表达意图：如 @ReadOnly（自定义）、@Unmodifiable（Checker Framework），虽不强制，但提升协作清晰度
final 参数唯一靠谱的用途
它不是安全机制，而是**设计信号和防错提示**：
- 在 lambda 或函数式接口中强调“这个回调实例不会被替换”，比如 Consumer
final handler - 配合 IDE 提示，提前发现局部变量重复赋值逻辑（尤其 for 循环里误写 i = 0）
- 团队规范中统一标记“该参数仅读取，不用于重绑定”，降低理解成本
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
