final参数仅可靠阻止变量引用被意外重赋值，即锁定变量名绑定的引用地址：基本类型值不可变，引用类型仍可修改对象状态，string不可变源于自身设计而非final修饰。
final 修饰方法参数，不能“确保对象不被篡改”，但能**可靠阻止变量引用被意外重赋值**——这是它唯一、明确、编译期强制生效的作用。理解这一点，才能用得准、不踩坑。
它真正锁住的是什么
final 参数只锁定「变量名绑定的引用地址」，不是对象本身的状态：
-
基本类型（int、boolean、double 等）：值不可变。声明
final int port = 8080;后，port = 8081;直接编译报错。 -
引用类型（List、StringBuilder、自定义对象等）：只能防止你写
list = new ArrayList();或sb = null;；但list.add("x")、sb.append("y")全部合法且会真实修改原对象。 -
String 是个特例：它不可变，靠的是自身类设计（内部 char[] 用 final + 不暴露修改接口），和你加不加
final String s没关系。
哪些实战场景下加 final 真有实效
不是所有地方都值得加，只在以下具体情形中，它能带来可验证的价值：
-
避免 for 循环变量覆盖：比如方法接收
final int timeout，你在方法里写for (int timeout = 0; ...)会立即编译失败，暴露出命名冲突。 -
lambda / 匿名内部类必须捕获：JDK 8+ 要求被捕获的局部变量必须是 effectively final。显式写
final String id = req.getId();，再在异步回调中使用，既安全又清晰，否则编译不过。 - 表达“只读引用”意图：配合 IDE（如 IntelliJ）的 “Parameter can be final” 提示，加 final 是向协作者声明：“我只用这个参数读取或调用方法，不会把它换成另一个对象”。这不是安全机制，而是沟通信号。
常见误用：以为加了 final 就安全了
这是最危险的认知偏差，容易导致线上问题：
- 声明
void handle(final List<string> items)</string>，却在里面调用items.clear()—— 编译通过，实参列表被清空。 - 以为
final User user能防止user.setName("hacker")—— 实际完全允许，除非 User 类本身是不可变设计。 - 把 final 当线程安全手段：多个线程同时调用
process(final Map m)，照样可能因并发修改引发ConcurrentModificationException。
真想保护内容，该怎么做
final 参数做不到的事，得靠其他手段补位：
-
传入前做防御性拷贝：对可变集合，用
new ArrayList(inputList)或 Java 10+ 的List.copyOf(inputList)（后者要求输入本身不可修改）。 -
返回时用不可变包装：如
Collections.unmodifiableList(result)，避免调用方反向污染。 -
优先使用天然不可变类型：String、Integer、LocalDateTime、Guava 的
ImmutableList.of()等。 -
敏感 DTO 做彻底不可变设计：字段全
private final，构造器初始化，只提供 getter，不提供 setter 或任何修改方法。
