在 spring web 应用中，为请求 dto（如 student）中的 list 类型字段（如 subjects）定义明确的空值语义至关重要：应统一拒绝 null，而接受空集合，以提升接口健壮性、简化业务逻辑并强化前后端契约。
在 spring web 应用中，为请求 dto（如 student）中的 list 类型字段（如 subjects）定义明确的空值语义至关重要：应统一拒绝 null，而接受空集合，以提升接口健壮性、简化业务逻辑并强化前后端契约。
在构建 RESTful API 时，Student 这类请求对象中 List<string> subjects</string> 的 null 处理并非技术细节，而是接口契约设计的核心环节。根据《Clean Code》倡导的“不传递 null”与“不返回 null”两大原则，后端应主动拒绝 subjects = null，而非在业务层做防御性判空。
✅ 推荐做法：强制 subjects 为非 null，允许空列表
@Data
@Builder
public class Student implements Serializable {
private String name;
@NotNull(message = "subjects must not be null")
private List<string> subjects;
}</string>
配合 Spring Validation（@Valid），在 Controller 层即可拦截非法请求：
@PostMapping("/students")
public ResponseEntity> create(@Valid @RequestBody Student student) {
// 此处 student.subjects 必然非 null —— 可直接遍历，无需 if (subjects != null)
for (String subject : student.getSubjects()) {
// 安全操作
}
return ResponseEntity.ok().build();
}
⚠️ 若放任 null 入参，将导致三重代价：
-
业务代码污染：每处使用前需
if (subjects != null)，重复且易遗漏； -
语义模糊：
null与[]在业务上常含义不同（如“未提供” vs “明确不选任何科目”），但前端难以准确表达意图； - 契约脆弱：前端若误传 null，错误延迟到业务层甚至 DAO 层才暴露，违反 fail-fast 原则。
? 进阶建议：
- 在 OpenAPI/Swagger 文档中明确标注
subjects为required: true，并说明其类型为array（非nullable: true）； - 前端 SDK 或表单提交逻辑默认初始化
subjects: []，避免因 JS 对象属性缺失导致 null； - 如需区分“未提供”和“提供空列表”，应引入显式状态字段（如
subjectsProvided: boolean），而非滥用 null。
综上，null 不是中立值，而是隐藏的 bug 温床。通过 Bean Validation 强制非 null + 默认空集合约定，既能保障代码简洁性，又能推动前后端达成清晰、可验证的接口契约。
