URL类仅解析和标准化资源地址，不发送网络请求；真正发起请求需用URLConnection；URL是URI子集，强调可定位性；构造成功不代表可达，超时和请求头等配置必须在URLConnection上显式设置。
URL 类不是 HTTP 客户端，它不发送请求
很多人一看到 URL 就默认它能“抓网页”，其实它只做一件事：解析和标准化字符串形式的资源地址。它不会打开连接、不会读响应体、也不会处理重定向或 Cookie。URL 对象创建成功，只代表语法合法，不代表目标可访问。
常见错误现象：new URL("https://example.com") 不抛异常，但后续调用 url.openStream() 才可能报 IOException；有人误以为构造失败 = 地址无效，其实构造阶段连 DNS 都不查。
- 真正发起网络请求得靠
url.openConnection()返回的URLConnection（或其子类HttpURLConnection） -
URL的getProtocol()、getHost()、getPath()等方法返回的是解析结果，不是运行时探测值 - 如果 URL 含中文或空格，必须先用
URLEncoder.encode()编码路径/参数部分，否则构造时可能抛MalformedURLException
URL 和 URI 的关键区别在哪
URL 是 URI 的子集，强调“可定位”（有协议、主机、端口等访问信息）；URI 更宽泛，比如 mailto:foo@example.com 或 urn:isbn:045228365X 是合法 URI，但不是 URL —— 它们不指向网络位置。
使用场景：如果你只是校验或拆解地址格式，用 URI 更安全（比如 new URI("foo/bar") 合法，但 new URL("foo/bar") 直接抛异常）；只有确定要打开网络连接时，才用 URL。
立即学习“Java免费学习笔记（深入）”；
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
-
URL重写了equals()和hashCode()，会尝试解析主机名（可能触发 DNS 查询），而URI是纯字符串比较 - 从字符串构建时，优先用
URI解析再转URL：先new URI(str).toURL()，避免因主机名大小写、默认端口省略等导致URL构造失败 -
URL不支持相对 URI 解析中的片段标识符（#后内容），而URI保留它
用 openConnection() 抓数据前必须设对这些参数
URL 自身不控制超时、重定向、User-Agent，这些全在 URLConnection 实例上配置。跳过这步，程序可能卡死、被服务器拒绝，或拿到 302 重定向响应体而非最终页面。
典型错误：直接 url.openStream()，结果遇到 HTTPS 重定向或需要 JS 渲染的页面就失效。
- 必须显式设置连接与读取超时：
conn.setConnectTimeout(5000)、conn.setReadTimeout(5000) - 关闭自动重定向：
conn.setInstanceFollowRedirects(false)，否则 301/302 响应会被静默处理，你拿不到原始响应头 - 伪造请求头：
conn.setRequestProperty("User-Agent", "Mozilla/5.0")，很多网站会拦截默认的 Java UA - 如果是 POST，需设
conn.setDoOutput(true)，并手动写入 body；GET 则不要设，否则可能出错
为什么有时候 new URL() 就抛 MalformedURLException
这不是网络问题，是字符串格式没过基本校验。Java 的 URL 构造器对协议名、分隔符、主机格式非常严格，稍有不符就炸。
常见触发点：协议后少了 ://、主机名含下划线、端口号超出 0–65535、IPv6 地址没用方括号包裹。
- 错误示例：
new URL("http:/example.com")（少一个/）、new URL("https://my_site.com")（主机含下划线）、new URL("https://[::1:8080")（IPv6 格式错） - 修复思路：先用正则粗筛（如
^https?://[^\s]+$），再用URI尝试解析——URI校验更宽松，且提供parseServerAuthority()等辅助方法 - 注意：空格、中文、
%编码不全的字符串，必须先URLEncoder.encode()路径和查询参数，不能只 encode 一部分
