getErrorStream()仅在HTTP响应码≥400时返回非null流，需先调用getResponseCode()判断；若≥400则用getErrorStream()读错误体，否则用getInputStream()读正常响应，且不可混用或提前触发响应解析。
当使用 HttpURLConnection 调用接口失败（如返回 4xx 或 5xx 状态码）时，getErrorStream() 是获取服务器返回的错误响应体（比如 JSON 错误信息、HTML 错误页等）的正确方式，但**必须先检查响应码是否表示错误，且不能在已调用 getInputStream() 后再调用它**——否则会抛出 IOException（“stream closed” 或 “already connected” 等）。
确保在读取错误流前确认是错误响应
getErrorStream() 只在 HTTP 响应状态码 ≥ 400 时返回非 null 的输入流。因此需先调用 getResponseCode() 判断：
- 若状态码 ≥ 400，才可安全调用
getErrorStream() - 若状态码 getErrorStream() 返回
null，此时应改用getInputStream() - 切勿在已调用
getInputStream()后再尝试getErrorStream()，连接内部流已被占用
典型错误处理结构（推荐写法）
以下为健壮的读取逻辑示例（伪代码逻辑，注意异常和资源关闭）：
- 执行
connection.connect() - 调用
int code = connection.getResponseCode() - 若
code >= 400：用connection.getErrorStream()读取错误内容 - 若
code ：用connection.getInputStream()读取正常响应 - 无论成功或失败，都通过
try-with-resources或finally关闭流
常见陷阱与修复
以下操作会导致 getErrorStream() 失效或抛异常：
-
提前触发响应解析：调用
getResponseMessage()、getHeaderFields()或任意读取响应头的方法，可能隐式触发连接建立并锁定流方向 -
重复调用输入流方法：对同一连接先后调用
getInputStream()和getErrorStream()会失败 -
忽略响应码直接读错误流：对 200 响应调用
getErrorStream()得到null，可能导致 NPE -
未设置
setDoInput(true)：默认为false，某些 JDK 版本下会导致无法读取任何响应流
调试建议
若仍拿不到错误响应体，可临时开启 HttpURLConnection 日志辅助排查：
- JDK 8+：启动时加 JVM 参数
-Djavax.net.debug=http - 或设置系统属性：
System.setProperty("sun.net.http.allowRestrictedHeaders", "true")（仅限必要调试） - 检查服务器是否真的返回了响应体（有些 404/500 响应可能为空）
- 用 curl 或 Postman 模拟相同请求，确认服务端行为一致
