Java中应优先用URI解析和构造资源标识，因其语法严格、不触发网络请求；仅在发起HTTP连接时才用URL或HttpClient，且后者直接接受URI参数。
Java中操作URL和URI，关键在于理解它们的语义差异和适用场景：URI是资源标识符（可能不包含访问协议），URL是URI的子集，特指可定位、可访问的资源地址。Java提供了java.net.URI和java.net.URL两个独立类，不能直接互转，必须通过字符串桥梁，且解析行为和校验严格度不同。
URI：专注语法合法性，适合解析和构造资源标识
URI类不关心资源是否存在，也不触发网络请求，只做RFC 3986规范下的语法解析与规范化。它支持相对URI解析、路径归一化（如../）、编码自动处理，适合用在配置、路由匹配、REST接口路径拼接等场景。
- 创建URI推荐用
new URI(String)，会严格校验格式；若含未编码字符（如中文、空格），需先用URLEncoder.encode()或使用多参数构造器（如new URI(scheme, userInfo, host, port, path, query, fragment)）避免异常 - 调用
resolve()可安全处理相对路径：base.resolve("sub/path")→ 自动合并路径、消除.. -
getScheme()、getHost()、getPath()等方法返回已解码后的字符串（如%E4%B8%AD变“中”），无需手动URLDecoder.decode()
URL：面向网络访问，自带协议处理器，但易受环境影响
URL类设计目标是打开连接（url.openConnection()），因此依赖JVM注册的URLStreamHandler（如http、file）。它的构造函数会尝试解析并标准化，但对非法字符容忍度高（比如空格不报错，内部转成%20），反而掩盖问题；且相同逻辑在不同JDK版本或自定义handler下行为可能不一致。
- 不要用
new URL(String)解析不可信输入——它可能静默修正错误，导致意外交互（如http://example.com/path?x=1 y被转成x=1%20y） - 获取主机名建议用
url.getHost()，但注意：若URL含用户信息（user:pass@host），getAuthority()才返回完整授权部分 - 想从URL提取纯路径？
url.getPath()返回解码后路径；但查询参数需用url.getQuery()单独获取，再自行解析
URI ↔ URL 转换：必须经由字符串，且注意编码陷阱
二者无继承关系，也不能强制转换。常见转换方式是“URL → 字符串 → URI”或反向，但中间字符串的编码状态决定结果是否正确。
立即学习“Java免费学习笔记（深入）”；
- 从URL转URI：用
url.toExternalForm()（非toString()）获取标准格式字符串，再传入new URI(...)。这样能保留原始编码，避免二次编码 - 从URI转URL：仅当URI有合法scheme（如
http、https、file）时才可调用uri.toURL()；若为相对URI或无scheme（如path/to/res），会抛IllegalArgumentException - 警惕陷阱：如果URI本身含未编码中文，
uri.toURL().toString()可能生成双编码URL（如%25E4%25B8%25AD），因为toString()会对已编码内容再编码
实际开发建议：优先用URI做解析，URL仅用于发起请求
日常开发中，90%的“处理链接”需求（如日志分析、API路径匹配、配置校验）都应使用URI——它稳定、轻量、符合标准。只有明确要打开HTTP连接、读取响应时，才用URL或更现代的java.net.http.HttpClient（它接受URI作为参数，不再强依赖URL类）。
- Spring、Jersey等框架内部大量使用
URI处理路径变量和模板，而非URL - JDK 11+推荐用
HttpClient.newBuilder().build().send(request, BodyHandlers.ofString())，其中request的uri()方法只接受URI对象 - 记录或展示链接时，统一用
uri.toString()（返回规范编码字符串），比url.toString()更可靠
