大型项目中POJO类字段冗余，本质是模型职责不清、数据来源混杂或历史演进导致的“字段堆积”。解决关键不在于删减本身，而在于厘清字段语义归属、统一数据源头、控制生成逻辑。以下四类实操路径覆盖大多数场景。
按语义归类，拆分职责边界
一个User类里同时存在user_name、profile_nickname、display_name、login_alias，表面是字段多，实则是身份标识、展示信息、登录凭证混在同一对象中。应按业务域拆分：
- 提取IdentityInfo承载唯一标识类字段（如id、loginId、mobile）
- 提取ProfileInfo承载用户画像类字段（如nickname、avatarUrl、bio）
- 提取DisplayConfig承载前端渲染策略字段（如theme、language、fontSize）
拆分后各子对象可独立演进、按需加载，避免DTO传输时携带大量无用字段。
用Lombok注解替代手写模板代码
字段本身不冗余，但配套的getter/setter/toString/equals方法成倍放大代码体积。Lombok在编译期注入，零运行时开销：
- 单字段控制：@Getter(onMethod_ = @Override) + @Setter(AccessLevel.PROTECTED) 精确控制访问权限
- 整类简化：@Data 已涵盖@Getter、@Setter、@ToString、@EqualsAndHashCode、@RequiredArgsConstructor
- 构造约束：@Builder + @AllArgsConstructor + @NoArgsConstructor 组合，支持链式构建与兼容序列化
- 非空保障：@NonNull 标记参数或字段，自动生成null校验逻辑
注意：Android项目需额外开启Annotation Processing，并使用compileOnly而非implementation引入Lombok依赖。
通过DTO层隔离冗余字段暴露
数据库实体（Entity）因历史原因保留冗余字段（如old_status、backup_phone），但API响应不应直接返回。必须通过DTO层做裁剪与映射：
- 定义UserResponseDTO仅包含前端真正需要的5个字段，不含任何历史冗余字段
- 用MapStruct或ModelMapper实现Entity→DTO自动转换，避免手写copy代码
- 对敏感字段（如passwordHash）在DTO中彻底移除，而非仅设为null
- 同一Entity可对应多个DTO（如AdminUserDTO含审核字段，SimpleUserDTO仅含基础信息）
识别并清理真冗余字段
真正该删除的字段，通常具备以下特征之一：
- 从未被任何DAO方法select、update或where条件引用（可通过SQL日志+代码搜索交叉验证）
- 值恒为NULL或默认值，且无业务规则依赖该字段存在
- 与其他字段语义完全重叠（如create_time与gmt_create共存，且始终同步更新）
- 属于已下线功能的残留字段（查Git历史确认最后一次修改时间早于下线日期）
清理前务必检查：数据库迁移脚本、MyBatis XML映射、Elasticsearch同步任务、缓存Key结构是否仍引用该字段。
