Spring Framework 6.2 版本中空响应Content-Type头行为变更解析

在Spring Framework 6.2版本（对应Spring Boot 3.4.0）中，开发团队对HTTP空响应的Content-Type头处理逻辑进行了调整。这一变更虽然微小，但对于依赖响应头校验的测试用例会产生直接影响。

行为变更详情

在先前版本中，当控制器方法返回Mono.empty()或Flux.empty()时，即使响应体为空，Spring仍会保留请求中声明的Content-Type头（如application/json）。但在6.2版本后，框架将更严格地遵循HTTP规范——对于没有实际响应体的请求，Content-Type头会被自动置为null。

技术背景

这种调整源于对RFC 7231协议的更准确实现。HTTP规范明确指出：

1. Content-Type头应当描述实际传输的body内容类型
2. 当响应体长度为0时，不应携带无关的Content-Type头
3. 这避免了客户端对空响应进行不必要的内容解析尝试

影响范围

主要影响两类场景：

1. 测试用例中显式检查Content-Type头的断言
2. 前端代码依赖Content-Type进行响应处理的逻辑

解决方案

对于必须保留Content-Type头的场景，开发者可以：

1. 显式返回ResponseEntity.noContent()并手动设置头信息
2. 返回带有包装结构的空JSON（如{"data":null}）
3. 更新测试断言，对空响应不再检查Content-Type

最佳实践建议

1. 在契约测试中区分有/无内容响应的头信息校验
2. 考虑使用Spring HATEOAS的RepresentationModel处理空响应
3. 对于REST API设计，建议始终返回结构化的响应体

该变更体现了Spring团队对HTTP协议规范性的持续改进，虽然带来短暂的适配成本，但有助于构建更符合标准的Web应用。