HttpURLConnection发GET请求最稳：需设超时、禁重定向、检查响应码、显式指定字符集、用try-with-resources关流、加User-Agent和Accept头、避免复用conn、并发用ExecutorService独立创建连接。
Java里用HttpURLConnection发GET请求最稳
别一上来就找第三方库，HttpURLConnection 是JDK自带、无依赖、够用。它不自动重定向、不自动解压、不缓存响应体——看似麻烦，实则是可控性的来源。
常见错误是没设 connectTimeout 和 readTimeout，导致线程卡死；还有忽略 setInstanceFollowRedirects(false)，结果302跳转后状态码还是200，但内容已是重定向HTML。
- 必须调用
setRequestMethod("GET")，否则某些JDK版本默认为POST - 记得在
getInputStream()前先检查getResponseCode()，4xx/5xx时该用getErrorStream() - 读取流后务必调用
disconnect()，否则连接可能堆积（尤其在循环爬多URL时）
用try-with-resources安全读取响应流
手动关流容易漏，InputStream 和 BufferedReader 都支持自动关闭，但要注意顺序：外层包装流必须在内层之前声明。
别用 response.toString() 或直接转String——HTTP响应可能含BOM、编码不一致，InputStreamReader 必须显式指定字符集，比如 UTF-8。
立即学习“Java免费学习笔记（深入）”；
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 优先用
new InputStreamReader(conn.getInputStream(), StandardCharsets.UTF_8)，而非new InputStreamReader(conn.getInputStream()) - 如果响应头里有
Content-Type: text/html; charset=gbk，就得按gbk解码，硬写UTF-8会乱码 - 大响应体别一次性
readAllBytes()，内存爆得悄无声息；用BufferedReader.readLine()流式处理更稳妥
遇到403或空响应？先看User-Agent和Accept头
多数网站对无 User-Agent 的请求直接返回403或空体，不是代码错，是被服务端拦截了。
Accept 头也关键：不设的话，有些API只返回JSON，但默认值可能是 */*，触发降级返回HTML；设成 application/json 才能拿到结构化数据。
- 必须调用
conn.setRequestProperty("User-Agent", "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36") - 加
conn.setRequestProperty("Accept", "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8")模拟浏览器行为 - 别学网上示例写
"Connection: keep-alive"——HttpURLConnection默认就复用连接，手动设反而干扰内部逻辑
别在主线程里跑多个URL，小心DNS阻塞和TCP等待
单线程串行请求，每个都要经历DNS解析→TCP握手→TLS协商→发送→等待→读取，耗时全叠加。并发不是靠开10个线程就完事，得控制连接池和超时。
真要并发，用 ExecutorService + Future，但每个 HttpURLConnection 实例必须独立创建——复用同一个conn对象在多线程下会出错。
- 每轮请求前 new 一个
URL(url).openConnection()，别缓存conn对象 - DNS问题常被忽略：本地hosts没配、运营商DNS污染，可临时改
System.setProperty("sun.net.inetaddr.ttl", "0")禁用JVM DNS缓存 - 如果目标站有反爬，
Thread.sleep(1000)比暴力并发更有效，也更不容易被封IP
真正难的从来不是连上URL，而是判断响应是否“可用”：状态码200不代表HTML结构没变，Content-Length: 0 不代表一定失败，有时候是JS渲染页。这时候光靠流处理不够，得接解析层——但那是另一个问题了。
