通过自定义注解 + Hibernate Validator 实现 DTO 中只读 ID 字段的静态校验，确保 POST/PUT 请求中显式传入 id 时立即返回 400 错误，避免后续抛出 500 异常。
通过自定义注解 + hibernate validator 实现 dto 中只读 id 字段的静态校验，确保 post/put 请求中显式传入 `id` 时立即返回 400 错误，避免后续抛出 500 异常。
在 REST API 开发中，id 字段通常由服务端生成（如数据库自增、UUID 或 Snowflake），客户端不应也不允许提供该值。若客户端在 POST/PUT 请求中携带 id，理想行为是在数据绑定与校验阶段即拦截并返回 400 Bad Request，而非等到持久化时因 Detached Entity 等问题抛出 500 Internal Server Error。
直接使用 @Null 是最简洁、标准且零侵入的解决方案——它属于 Jakarta Bean Validation 规范，无需额外逻辑即可实现“禁止非 null 值”的静态校验：
@Data
@AllArgsConstructor
@NoArgsConstructor
@Builder
public class SampleApiDto {
@Null(message = "id must not be provided in request payload")
private Long id; // 注意：使用包装类型 Long，而非基本类型 long（否则无法为 null）
private String description;
private String columnName;
private String code;
}
✅ 关键要点说明：
- 必须将 private long id 改为 private Long id：基本类型 long 默认值为 0，无法为 null，导致 @Null 永远校验失败（或被忽略）；而 Long 可为 null，且 JSON 反序列化时若字段缺失或为 null，将正确设为 null。
- @Null 在 @Valid 触发时自动生效（如 Spring MVC 中控制器参数标注 @Valid）：
@PostMapping public ResponseEntity> create(@Valid @RequestBody SampleApiDto dto) { ... } - 校验失败时，Spring Boot 自动返回 400 Bad Request 及标准化错误体（含 message），符合 REST 最佳实践。
⚠️ 不推荐方案辨析：
- @JsonIgnore（或 @JsonIgnoreProperties）仅影响 JSON 序列化/反序列化，不参与校验，且会彻底丢失 id 字段值，违背“ID 需在 DTO 中后续被数据层使用”的需求。
- 单独创建 InputDTO（如 SampleCreateRequest）虽更严格分层，但需额外类与映射逻辑，在已有 DTO 广泛复用的大型项目中，增加维护成本；而 @Null 方案零侵入、零重构、语义清晰，是更优解。
- 自定义注解（如 @ReadOnlyId）虽可行，但过度设计：@Null 已精确表达“该字段不允许客户端设置”的业务语义，无需重复造轮子。
? 进阶建议（可选）：
若需区分 POST（禁止 id）与 PUT（允许 id，但仅限路径参数或特定场景），可结合 @GroupSequence 或 @Validated 分组校验，但对本例而言，统一禁止客户端传 id 是更安全、更易维护的设计。
综上，将 id 改为 Long 并添加 @Null 注解，是最轻量、最规范、最易落地的静态校验方案。
