final参数只锁住变量名指向的地址，不锁住对象内部状态；如final List<String>不可重新赋值，但list.add("x")合法。
final参数到底锁住了什么
它只锁住「变量名指向的地址」，不锁住对象内部状态。传一个final List<String>进去，你不能重新赋值给这个形参，但list.add("x")完全合法。
什么时候加final真有用
常见于 Lambda 表达式捕获、匿名内部类访问，或者明确想向调用方传递「这个参数我只读」的语义。JVM 不强制检查，但 IDE 和静态分析工具（比如 IntelliJ）会据此给出警告或补全提示。
- Lambda 中引用外部局部变量时，该变量必须是
final或「事实 final」（Java 8+ 允许不写final，但编译器仍要求不可变） - 方法签名里加
final对调用方无影响，不改变字节码行为，纯属 API 意图表达 - 对基本类型（
int、boolean）加final才真正禁止修改值
不加final也可能被误改
典型陷阱是把可变对象当「只读输入」用，结果方法里悄悄改了它的内容，调用方一脸懵。这不是 final 能拦住的——它拦不住 map.put()、buffer.append() 这类操作。
- 真正需要保护输入数据时，得靠深拷贝、不可变容器（如
ImmutableList）、或文档约定 -
final参数 + 修改对象内容 = 隐蔽副作用，比不加final更容易让人放松警惕 - IDE 自动生成的方法存根默认带
final，别无脑接受，先想清楚这个参数在逻辑上是不是真的不该被重新赋值
编译后其实没区别
final 修饰参数不会出现在字节码里，javap -c 看不到任何额外指令。它只在编译期起作用，用于约束开发者、辅助工具链推理。
立即学习“Java免费学习笔记（深入）”；
- 反射获取方法参数时，拿不到
final标记（Parameter.isNamePresent()也不管这个） - ProGuard / R8 等混淆器也不会因为
final改变优化策略 - 如果真要靠语言机制防篡改，得用
record、sealed或者手动封装成不可变视图
final 参数最容易被当成「安全错觉」——以为加了就万事大吉，结果对象内部早被改得面目全非。真正关键的是区分「引用不变」和「状态不变」，后者从来不是 final 的责任。 
