Java17下Gson适配：无参构造器vs类型适配器（弃用sun.misc.Unsafe）

首选方案：移除final修饰符+添加无参构造器 #

这是最省心高效的选择，核心原因如下：

• 操作成本极低：借助IDE的批量重构功能（比如IntelliJ的批量替换、批量生成无参构造器），100多个类能快速完成修改，无需编写额外业务外的代码。
• 贴合Gson原生逻辑：禁用Unsafe后，Gson默认依赖无参构造器+反射赋值字段，这种方式完全匹配它的常规工作流程，后续维护、排查序列化问题都简单，团队新人也能快速理解。
• 业务兼容：如果原本的final是为了对外保证字段只读，你可以保留类的get方法，仅去掉字段的final修饰符，内部业务逻辑不受影响，对外依然保持只读特性，只是给Gson留出赋值入口。

不推荐手动编写类型适配器 #

这个方案性价比极低，不建议采用：

• 100多个类逐个编写适配器，工作量巨大，且后续POJO字段修改时，必须同步更新对应适配器，极易漏改引发隐藏bug。
• 就算使用自动生成适配器的第三方库，也会额外引入依赖，增加项目复杂度，生成的代码可读性差，排查序列化问题时会更费劲。

折中方案：保留final但添加全参构造器+@SerializedName #

如果业务上对字段不可变性有强制要求，可以给每个POJO添加包含所有字段的全参构造器，同时给每个字段加上@SerializedName注解。Gson禁用Unsafe后，会通过反射调用这个全参构造器创建对象，无需修改final修饰符。不过该方案工作量比第一种大，适合部分对不可变性要求极高的类，不建议全量应用。

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