java的httpurlconnection默认自动处理重定向，导致`getresponsecode()`返回最终响应（如200）而非原始302，需显式禁用自动重定向才能获取真实跳转状态。
在使用 HttpURLConnection 检测服务器是否发起重定向时，一个常见误区是：期望看到原始的 302 状态码，却实际收到 200 OK。这并非网络或服务端问题（Wireshark 已证实服务端确实返回了 302），而是 Java 客户端的默认行为所致。
HttpURLConnection 默认启用自动重定向（setInstanceFollowRedirects(true)），当收到 302 响应时，它会自动发起第二次请求（即向 Location 头指定的 URL 发起新 GET），并将第二次响应（如 pg_2.php 返回的 200）作为最终结果暴露给开发者。因此，getResponseCode() 和 getHeaderFields() 获取的都是重定向后目标页面的响应信息，原始 302 已被“吞掉”。
✅ 正确做法：在调用 connect() 前，显式关闭自动重定向：
URL url = new URL("http://localhost/test/test_page_1.php");
HttpURLConnection connection = (HttpURLConnection) url.openConnection();
connection.setInstanceFollowRedirects(false); // ? 关键：禁用自动跳转
connection.setRequestMethod("GET");
connection.connect();
int responseCode = connection.getResponseCode();
System.out.println("Actual status code: " + responseCode); // 输出：302
// 可进一步检查重定向目标
String location = connection.getHeaderField("Location");
System.out.println("Redirect to: " + location); // 输出：pg_2.php⚠️ 注意事项：
立即学习“Java免费学习笔记（深入）”；
- setInstanceFollowRedirects(false) 仅影响当前连接实例，不会改变全局行为；
- 若需手动处理重定向逻辑（如记录跳转链、验证中间状态），务必关闭自动跳转，并自行解析 Location 头、构造新请求；
- 对于 HTTPS 或复杂认证场景，还需注意 Cookie、认证头等是否需手动透传至后续请求；
- Java 11+ 推荐使用 HttpClient（支持 HttpResponse.BodyHandlers.ofString() 等现代API），其重定向策略更明确（通过 HttpRequest.Builder::followRedirects() 控制），但底层逻辑一致：不自动跳转 = 才能观测原始 302。
总结：要调试或检测重定向行为，必须主动“拦截”跳转过程——禁用 HttpURLConnection 的自动重定向机制，这是获取真实 HTTP 状态码的前提。
