pojo变量状态保护核心是严格遵循javabeans规范：布尔字段命名须语义化（如enabled）、getter用isxxx()，字段名禁用is前缀；驼峰命名、无参/全参构造器、lombok组合注解（@getter/@setter/@noargsconstructor/@allargsconstructor）更可控。
POJO类中变量状态保护，核心在于Getter/Setter的命名与行为必须严格遵循JavaBeans规范，否则框架反射失效、序列化异常、布尔字段误判等问题会集中爆发。
布尔类型字段：命名和getter必须匹配规范
原始boolean字段如private boolean active;，其getter必须是isActive()，不能写成getActive()；若字段名本身带is前缀（如private boolean isActive;），框架反向推导时会误判属性名为active，导致JSON解析为{"active":true}却无法映射回字段——这是Dubbo、FastJSON、MyBatis等常见报错根源。
- 推荐做法：布尔字段统一用语义化名称（如
enabled、locked），不加is前缀 - 包装类型
Boolean字段（如private Boolean deleted;）也应使用isDeleted()，而非getDeleted()，保持行为一致 - IDE自动生成时需人工核对：Eclipse/IntelliJ默认对boolean字段生成
isXxx()，但若字段名含is，务必手动修正
字段命名与getter/setter映射必须可逆
Java框架通过“去掉get/is前缀 + 首字母小写”规则还原属性名。例如：getUserName() → 推导出字段名userName；isFinished() → 推导出finished。若字段实际为user_name，则生成getUserName()会导致映射失败——这不是Getter写错了，而是POJO字段命名本身违反规范。
- POJO字段必须用标准驼峰命名（如
lastLoginTime），数据库列名差异应在ORM层（如MyBatis的@Results或JPA的@Column）处理 - 避免下划线命名直接进POJO，否则getter/setter生成后无法被Jackson或Spring MVC正确绑定
- 字段名含数字开头（如
3gEnabled）时，getter应为is3gEnabled()，JavaBeans规范允许，但部分老框架支持不佳，建议改用enabled3g
构造器与访问控制是状态保护的第一道门
仅靠getter/setter无法真正保护状态。一个可被随意new并set任意值的POJO，本质上仍是裸数据。真正的状态保护需要结合构造约束与访问级别设计。
- 必须提供无参构造器（供框架反射实例化），同时提供全参构造器（用于构建不可变或强校验场景）
- 敏感字段（如
password）的setter可加入逻辑校验（如非空、长度、加密前校验），而getter可返回脱敏值（如"***"） - 若字段不应被外部修改，setter可设为
protected或private，或干脆不提供setter，改用Builder模式初始化
用Lombok简化但不替代规范理解
@Data、@Getter/@Setter确实能一键生成方法，但Lombok只是工具，它不会纠正你错误的字段命名或类型选择。比如：@Data对private boolean isDeleted;仍会生成isDeleted()，但框架仍会把它当deleted处理——问题照旧。
- 推荐组合：
@Getter @Setter @NoArgsConstructor @AllArgsConstructor，比@Data更可控，避免意外生成toString()或equals()引发性能或安全问题 - 对布尔字段，Lombok默认生成
isXxx()，符合规范；但若你用了@Setter单独标注某字段，需确认其类型是否为boolean - 禁用特定字段的getter：用
@Getter(AccessLevel.NONE)，比手写空方法更清晰
