将DA层的id参数设为final会有何影响？为何少见此做法？

一、将id参数设为final的直接后果 #

• 编译期赋值限制：如果是方法参数声明为final，在方法内部绝对不能对该id变量重新赋值，编译器会直接抛出错误。比如你想在DA层方法里临时修改id的值（比如拼接租户前缀、转换类型后重新赋值给变量），这种操作会被直接禁止。
• 无运行时性能波动：final修饰参数是纯编译期检查，不会改变Java字节码的执行逻辑，既不会带来性能提升，也不会产生额外损耗，JVM运行时不会因为这个修饰符做特殊处理。
• 可读性的明确提示：能直接告诉后续维护者，这个id参数在当前方法内不会被修改，减少阅读代码时的心智负担，不用额外追踪变量是否被重新赋值。
• 适配Lambda/匿名内部类：如果DA层方法内需要在Lambda表达式或匿名内部类中引用该id参数，final修饰（或者实际未被重新赋值的“有效final”）是必要条件，提前声明final可以避免后续修改代码时突然出现编译错误。

二、为何极少有软件采用这种做法 #

• 无强制必要性：DA层的id参数大多用于SQL查询、更新的条件，业务逻辑本身就不会去修改它，即使不声明final，实际代码也不会对其赋值。既然没有实际的错误风险，很多开发者觉得多写一个final属于冗余操作。
• 编码习惯的惯性：大部分Java开发者的编码习惯里，只有在必要时（比如Lambda引用场景）才会给参数加final，日常开发中不会主动给所有不会修改的参数都加上这个修饰符，属于约定俗成的“偷懒”。
• ORM框架自动生成代码的影响：很多项目用MyBatis、JPA等ORM框架自动生成DA层代码，这些框架生成的方法参数默认不会带final，开发者通常不会特意去修改自动生成的代码，导致这种做法普及度极低。
• 预留场景灵活性：虽然业务上id通常不会变，但特殊场景下可能需要临时调整id（比如多租户场景加前缀、分库分表时修改id路由规则），提前加final会限制这种灵活调整的可能性，开发者更倾向于保留这种潜在的灵活性。

内容的提问来源于stack exchange，提问作者lWubaLubaDubDubl