URL类不能直接解析域名和端口，仅做语法校验与结构封装；getHost()和getPort()提取显式指定的主机与端口，不补默认值、不验证可达性；需用URI处理相对路径、标准化及安全哈希。
URL类能直接解析域名和端口吗
不能。URL 类本身不提供“解析”能力，它只是对输入字符串做基础校验和结构化封装。调用 new URL("https://example.com:8080/path?x=1") 后，getHost() 返回 "example.com"，getPort() 返回 8080（如果显式写了），但不会自动识别 www.example.com 和 example.com 是否同站，也不会判断端口是否有效或服务是否可达。
常见错误是以为 URL 构造成功就代表地址合法——其实它只校验语法，不校验 DNS 可达性或协议支持。比如 new URL("http://[::1]:999999/") 会抛 java.net.MalformedURLException（端口超范围），但 new URL("http://invalid-host-123/") 能成功构造，直到调用 openConnection() 才真正触发 DNS 查询并可能失败。
getAuthority() 和 getHost() + getPort() 的区别
getAuthority() 返回原始字符串中 // 后、/ 前的部分（如 "user:pass@host:8080"），而 getHost() 只提取主机名或 IP，getPort() 提取端口号（若未显式指定则返回 -1）。
-
new URL("https://user:pass@example.com:8080/a").getAuthority()→"user:pass@example.com:8080" -
getHost()→"example.com"，getPort()→8080 - 若 URL 是
"https://example.com/a"，getAuthority()是"example.com"，getPort()是-1（不是443）
注意：getPort() 永远不会自动补默认端口（80/443），这是和浏览器行为的关键差异。需要默认端口逻辑必须自己判断协议再硬编码。
立即学习“Java免费学习笔记（深入）”；
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
为什么 getPath() 不包含查询参数
getPath() 只返回路径部分（/path/to），不包括 ?key=value 或 #fragment。查询参数需用 getQuery() 单独获取，片段标识符用 getRef()。
容易踩的坑：
- 拼接重定向 URL 时直接用
getPath()+"?a=1"，结果漏掉原查询参数 - 误把
getQuery()当成已解码的值——它返回的是原始 URL 编码字符串（如"q=hello%20world"），需手动调用URLDecoder.decode(query, "UTF-8") -
getRef()返回null如果 URL 没有#，不是空字符串
URL 和 URI 的选择：什么时候该换用 URI
当需要处理相对路径解析、标准化路径（如 ../ 归一化）、或严格区分 scheme-specific 部分时，URI 更可靠。URL 是 URI 的子集，但强制要求可解析（即必须有协议处理器），且 equals() 方法会尝试 DNS 解析（可能阻塞或失败）。
典型场景：
- 配置文件里存路径模板：
new URI("/api/v1/users/{id}")——URL不接受无协议的字符串 - 拼接父子路径：
base.resolve(relative)在URI中安全，在URL中可能因协议处理器缺失抛异常 - 做哈希或缓存键：
URI.equals()是纯字符串语义，URL.equals()可能触发网络操作
实际项目中，除非明确要发起 HTTP 请求，否则优先用 URI 处理地址结构；URL 仅在需要 openConnection() 或与旧 API 兼容时使用。
