URL类不负责解析URL字符串，仅封装RFC规范URL并提供getter方法访问字段，解析为懒加载；URI类则在构造时严格校验语法，支持归一化、编码解码等，是更安全可靠的替代方案。
Java中的URL类本身不负责解析URL字符串的结构，它只是封装一个符合RFC规范的统一资源定位符，并提供获取协议、主机、端口、路径等字段的访问方法；真正的解析动作在构
URL对象时由内部完成，且是“懒解析”——只在首次调用getProtocol()、getHost()等方法时才真正拆解。
URL类如何提取各部分组件
URL对象通过一系列getter方法暴露已解析的字段，这些值在第一次访问时被计算并缓存。常见方法包括：
-
getProtocol()：返回协议名，如"https"（注意全小写） -
getHost()：返回主机名，对https://user:pass@sub.example.com:8080/path返回"sub.example.com" -
getPort()：返回端口号，若URL中未显式指定则返回-1（表示使用默认端口） -
getPath()：返回路径部分，含开头的/，如"/api/v1/users" -
getQuery()：返回问号后的查询参数字符串，如"id=123&name=foo" -
getRef()：返回片段标识符（#后内容），如"section2"
URL解析的限制与注意事项
URL类的设计目标是网络连接而非通用URL处理，因此有明显局限：
- 不校验URL语义合法性——
new URL("http://")能构造成功，但后续openConnection()会失败 - 不自动解码URL编码（如
%20），getPath()返回的是原始编码字符串；需手动用URLDecoder.decode(path, "UTF-8") - 对相对URL支持弱，
resolve()方法仅做简单拼接，不处理../或./归一化 - 无法直接获取用户名/密码（
getUserInfo()返回完整"user:pass"，且不推荐用于敏感信息）
更安全可靠的替代方案：URI类
若需健壮的解析、验证或构建能力，应优先使用java.net.URI：
-
URI在构造时就严格校验语法，非法URL会抛URISyntaxException - 提供
getScheme()、getAuthority()、normalize()、resolve()等更精确的方法 - 支持
encodeComponent()和decode()，与编码逻辑天然契合 - 可无损转换：
new URL(uri.toString())或uri.toURL()（但后者可能抛MalformedURLException）
实际使用建议
日常开发中按场景选择：
- 只需发起HTTP请求？直接用
new URL("...").openConnection()，不用深究解析细节 - 要从URL中取主机、路径做路由或鉴权？先转成
URI再取字段，避免URL的隐式行为陷阱 - 需拼接或生成URL？用
UriComponentsBuilder（Spring）或java.net.http.HttpClient配套的HttpRequest.Builder更安全 - 处理用户输入的URL？务必用
URI构造并捕获异常，再决定是否继续
基本上就这些。URL类够用但粗糙，URI才是现代Java里真正靠谱的URL工具。
