final修饰方法参数仅阻止参数变量重新赋值，不防止对象内容修改；对基本类型禁值变更，对引用类型仅禁引用重赋值，String不可变源于自身设计而非final。
final 修饰方法参数不能确保对象内容不被篡改，它只阻止对参数变量本身重新赋值。 想靠 final 防止 list.add() 或 obj.setName() 这类操作？行不通。这是最常见的认知偏差，也是最危险的误用起点。
final 参数到底锁住了什么
它只锁定“变量名绑定的引用地址”，不是对象状态。比如：
void process(final StringBuilder sb) {
sb.append("hello"); // ✅ 允许：修改对象内部
sb = new StringBuilder(); // ❌ 编译报错：不能重赋值
}
- 对基本类型（
int、boolean）：值不可变，final int x = 5;后不能x = 10; - 对引用类型（
ArrayList、StringBuilder）：只能保证你不会写list = new ArrayList();，但list.clear()、list.add()全部照常 - String 是个特例——它不可变，但那是因为
String类的设计，不是final参数的功劳
哪些场景下加 final 真有实际价值
真正起效的场合非常具体，不是泛泛“防篡改”：
- 在 lambda 表达式或匿名内部类中捕获局部变量时，Java 要求该变量必须是 effectively final；显式加
final能提前暴露问题，避免编译失败 - 方法内有同名局部变量（如循环变量
i），加final可防止意外覆盖传入参数：for (int i = 0; i 和 <code>final int i冲突，立刻暴露命名冲突 - 团队统一启用 IDE 的 “Parameter can be final” 检查时，作为语义提示：这个参数我只读，不打算重赋值——仅此而已，和安全性无关
想真正保护参数内容，该怎么做
靠 final 不行，得换思路：
- 接收可变集合时，做防御性拷贝：
new ArrayList(inputList)或 Java 10+ 的List.copyOf(inputList)（后者要求输入不可修改） - 返回集合优先用
Collections.unmodifiableList()，而不是指望入参是final - 对敏感对象（如配置 DTO），构造时校验 + 字段全用
private final+ 只读 getter - 必要时手动 deep copy，或使用不可变库（如 Guava 的
ImmutableList）
最容易被忽略的一点：把「变量不可重赋值」当成「对象不可修改」，这种误解比漏写 final 严重得多——它会让人在关键路径上产生虚假的安全感。
