final修饰方法参数仅防止参数变量被重新赋值，不能阻止对象内容被修改；因java是值传递，传入的是引用副本，final无法限制对象内部状态变更。
final 修饰方法参数不能确保“对象内容不被篡改”，只能防止参数变量本身被重新赋值。 这是 Java 中最常被误解的语义之一——加了 final 不等于锁住对象，更不等于线程安全或输入防护。
为什么 final 参数无法阻止对象内部被修改
Java 是值传递，传入的是引用的副本。对引用类型参数加 final，只禁止你写 param = new SomeClass() 或 param = null；但完全允许调用 param.add(...)、param.setName(...) 等改变对象状态的操作。
常见错误现象：
- 声明
void process(final List<string> list)</string>，却在方法里执行list.clear()—— 编译通过，运行时 list 被清空 - 传入一个
final StringBuilder sb，然后写sb.append("x")—— 合法，且实参对象状态已变 - 以为加了
final就能避免并发修改异常（ConcurrentModificationException）—— 实际毫无作用
什么情况下 final 参数真正有用
它只在「变量重赋值」这个窄维度上有约束力，适用场景有限但明确：
- 基本类型参数（
int、boolean、double）：加final可防止意外覆盖，比如for (int i = 0; i 这类低级错误 - lambda 表达式中捕获局部变量：JDK 8+ 要求被捕获变量必须是“effectively final”，加显式
final能提前暴露潜在赋值冲突 - 回调接口或函数式参数（如
Runnable、Consumer<t></t>）：强调该参数仅作调用入口，不应被替换为另一个实例 - 配合 IDE 提示或团队规范，表达“此参数仅读取，不重绑定”的设计意图（非强制安全机制）
想真正防止对象被修改，该怎么做
靠 final 参数做不到，必须换思路：
- 传入不可变对象：优先用
String、Integer、ImmutableList.of(...)（来自 Guava）等天然不可变类型 - 做防御性拷贝：对可变集合，用
new ArrayList(inputList)或Collections.unmodifiableList(inputList) - 校验 + 拒绝非法状态：在方法开头检查关键字段（如
if (list == null) throw ...），而非依赖修饰符 - 用注解辅助：如
@NonNull（JetBrains）、@Immutable（Checker Framework），配合静态检查工具
最容易被忽略的一点：把「引用不可重赋」当成「对象不可变」，这个认知偏差比漏写 final 危险得多。它会让人误以为加了就安全，结果在线上跑出难以复现的状态污染 bug。
