Micronaut框架中CompletableFuture端点重定向响应异常分析

问题现象

在Micronaut框架中，当开发者使用CompletableFuture作为端点返回类型时，如果尝试返回一个没有响应体但包含307重定向状态的HTTP响应，框架会错误地将其转换为200状态码。这个问题在Micronaut 4.x版本中出现，而在之前的版本中表现正常。

问题复现

考虑以下典型的重定向端点实现：

@Get("/redirect/fail")
CompletableFuture<MutableHttpResponse> redirectFail() {
    return CompletableFuture.completedFuture(
        HttpResponse.status(HttpStatus.TEMPORARY_REDIRECT)
            .header("Location", "http://foo.com")
            .header("Content-Length", "0")
            .header("Connection", "close")
    );
}

预期行为是返回307状态码，但实际却返回了200状态码。有趣的是，如果为响应添加一个空字符串作为响应体，问题就会消失：

return HttpResponse.status(HttpStatus.TEMPORARY_REDIRECT)
    .body("")  // 添加空响应体
    .header("Location", "http://foo.com")
    // 其他头部...

技术分析

深入Micronaut框架内部实现，问题根源在于路由执行器(RouteExecutor)对CompletableFuture类型响应的处理逻辑。当响应没有主体(body)时，框架会创建一个新的响应对象，但在这个过程中没有正确保留原始响应的状态码和自定义头部。

关键问题点在于：

1. 框架在处理异步响应时，对无内容响应的特殊处理逻辑
2. 状态码和自定义头部在响应转换过程中丢失
3. 只有当响应包含主体时，原始响应才会被完整保留

影响范围

这个问题会影响所有使用CompletableFuture作为返回类型且需要实现重定向功能的端点。特别是：

1. 临时重定向(307)和永久重定向(308)场景
2. 需要设置自定义HTTP头部的无内容响应
3. 依赖重定向状态码进行客户端处理的系统

解决方案

目前可行的临时解决方案包括：

1. 为响应添加空字符串主体（如上所示）
2. 使用同步端点替代CompletableFuture（如果不必须异步）
3. 实现自定义响应处理器来确保状态码保留

从框架设计角度看，正确的修复应该是在路由执行器中确保无论响应是否有主体，都能正确保留原始响应的状态码和头部信息。

最佳实践建议

在等待官方修复的同时，建议开发者：

1. 明确测试重定向端点的状态码断言
2. 考虑为所有重定向响应添加显式主体
3. 在升级Micronaut版本时，特别验证重定向功能
4. 关注框架更新日志中关于此问题的修复情况

这个问题提醒我们在使用响应式编程模型时，需要特别注意框架对异步响应处理的细节差异，特别是在状态码和头部信息保留方面的行为变化。