必须转型为HttpURLConnection才能发HTTP请求，因其是抽象类，不提供setRequestMethod等HTTP特有方法；需设超时、显式指定UTF-8编码、关闭自动重定向并手动处理状态码与重定向。
必须转型为 HttpURLConnection 才能发 HTTP 请求
URLConnection 是抽象类，不提供 setRequestMethod、getResponseCode、setRequestProperty 等 HTTP 特有方法。直接用它调 getInputStream()，遇到重定向、403、gzip 压缩时大概率抛 IOException 或返回空内容。
常见错误现象：
- 调
setRequestMethod("GET")无反应，或直接抛IllegalStateException - 把
404、500当作成功响应读取，结果拿到错误页 HTML 甚至空白 - 没设
User-Agent，被 GitHub、知乎等站点直接返回403 Forbidden
正确做法是强制转型：HttpURLConnection connection = (HttpURLConnection) url.openConnection();
setConnectTimeout 和 setReadTimeout 不是可选配置
默认超时是无限等待。网络抖动、DNS 解析慢、服务器假死都会让线程卡死，尤其在 Android 上可能触发 ANR。
立即学习“前端免费学习笔记（深入）”；
建议值：
-
setConnectTimeout(8000)：TCP 连接建立上限，低于 3000 容易误判正常波动 -
setReadTimeout(8000)：单次read()阻塞上限，不是整个响应读取总耗时 - 服务端批量采集可放宽到 15–30 秒，但必须配合重试逻辑
字符编码必须显式指定，不能靠系统默认
InputStreamReader 不会自动解析响应头里的 charset=utf-8。用 new InputStreamReader(conn.getInputStream()) 相当于用平台默认编码（Windows 是 GBK，Linux/macOS 是 UTF-8），一读中文就乱码。
稳妥做法：
- 优先用
StandardCharsets.UTF_8（Java 7+），覆盖绝大多数现代网站 - 若遇政府旧站等 GB2312/GBK 编码，再 fallback 到
"GBK" - 别依赖
connection.getContentType()解析 charset——有些响应头根本不带，有些带得不规范
示例：new InputStreamReader(connection.getInputStream(), StandardCharsets.UTF_8)
别忘了手动处理重定向和状态码
HttpURLConnection 默认开启自动重定向（setInstanceFollowRedirects(true)），但这样会丢失中间跳转信息，且无法统一控制重试或日志。更可控的做法是关掉它，自己处理：
- 调
setInstanceFollowRedirects(false) - 读
getResponseCode()，判断是否为HTTP_MOVED_PERM或HTTP_MOVED_TEMP - 从
getHeaderField("Location")提取新地址，递归或循环重试 - 非
HTTP_OK状态应明确抛异常，而不是静默读取
容易被忽略的点：很多代码只写了 try-with-resources 关流，却漏掉 connection.disconnect()；虽然 JVM 会回收，但在高并发场景下不显式断开可能拖慢连接复用或触发端口耗尽。
