Java中使用HttpURLConnection发送请求详解

本文深入剖析了Java中HttpURLConnection的使用陷阱与最佳实践，直击开发者常踩的“默认方法未设置导致IllegalStateException”“POST忘设doOutput=true”“响应中文乱码因未按Content-Type动态解码”“超时未预设引发线程阻塞”“错误复用实例或忽略getErrorStream致连接池卡死”等核心痛点，系统梳理了GET/POST配置差异、字符编码精准处理、超时与重定向控制、连接生命周期管理等关键细节，以实战视角揭示看似简单却极易出错的底层逻辑，助你写出稳定、健壮、符合HTTP语义的网络请求代码。

HttpURLConnection 默认是 GET 还是 POST？

默认是 GET，但必须显式调用 setRequestMethod("GET") 或 setRequestMethod("POST")，否则首次调用 connect() 或获取输入流时会抛 IllegalStateException: Already connected。很多人卡在这一步，以为没写就默认生效，其实它连方法名都没设好。

常见错误现象：java.lang.IllegalStateException: Already connected 或 java.net.ProtocolException: cannot write to a URLConnection if doOutput=false（想发 POST 却没设 setDoOutput(true)）。

• GET 请求：设 setDoOutput(false)（默认值），参数拼在 URL 后，如 ?name=jack&age=25
• POST 请求：必须设 setDoOutput(true)，且通常要设 setRequestProperty("Content-Type", "application/x-www-form-urlencoded")
• 若发 JSON，Content-Type 应为 application/json; charset=utf-8，并手动写入 UTF-8 字节（别用 String.getBytes() 无参版）

如何正确读取响应体并避免中文乱码？

响应体乱码不是因为没设 charset，而是没用对编码方式。HttpURLConnection 不自动解析 Content-Type 中的 charset 参数，getInputStream() 返回的是原始字节流，必须自己按正确编码解码。

实操建议：

• 先用 getContentType() 拿到响应头，正则提取 charset=xxx，没匹配到就 fallback 到 UTF-8
• 别用 new String(bytes)，改用 new String(bytes, StandardCharsets.UTF_8) 或动态 charset
• 如果服务端返回 Content-Type: text/html; charset=gbk，你就得用 GBK 解码，否则中文全成
• 注意：即使设了 setRequestProperty("Accept-Charset", "utf-8")，服务端也不一定遵守——这是请求头，不决定响应编码

超时、重定向和连接复用怎么控制？

HttpURLConnection 默认启用 HTTP 重定向（301/302），且默认超时是无限的，这在线上环境极易引发线程阻塞。连接复用靠底层 Keep-Alive，但 Java 7+ 默认开启，无需手动配置，反而要注意关不干净的问题。

• 设超时：必须在 connect() 前调用 setConnectTimeout(5000) 和 setReadTimeout(10000)，单位毫秒
• 禁用重定向：调用 setInstanceFollowRedirects(false)，之后可手动处理 getResponseCode() 是否为 3xx
• 强制关闭连接：调用完 getInputStream() 或 getErrorStream() 后，务必 disconnect()；但注意：调用 disconnect() 并不立即释放 socket，只是标记为可回收
• 别反复复用同一个 HttpURLConnection 实例：它不可重入，每次新请求都应新建实例

为什么有时 getResponseCode() 报 IOException？

这不是“偶尔出错”，而是 HttpURLConnection 在底层 HTTP 状态线未就绪时，强行读响应码触发了连接异常。典型场景是：没调用 connect() 就直接 getResponseCode()，或已调用 getInputStream() 再去读状态码（流已消费，状态可能丢失）。

正确顺序只有一条路径：

• 创建连接 → setRequestMethod / setDoOutput / setRequestProperty → connect()（或隐式触发）
• 发数据（仅 POST）→ getOutputStream().write(...) → flush() → close()
• 再调用 getResponseCode() → 根据状态码决定走 getInputStream() 还是 getErrorStream()
• 最后关流、disconnect()

最容易被忽略的是：即使请求失败（如 404、500），也必须调用 getErrorStream() 读完内容，否则下一次复用连接池时可能卡住——JVM 的 keep-alive 机制依赖流是否彻底读尽。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。