应使用 URI 类替代 URL 类进行 URL 字符串的结构化解析，因为 URI 是纯语法解析器，构造时即校验格式、各组件 getter 行为稳定，且支持自动编码和相对路径解析；而 URL 的解析依赖协议处理器、未连接前字段可能为空或默认值，且不校验路径合法性。
Java 的 URL 类本身不解析 URL，它只是封装和标准化地址字符串；真正做解析的是其内部的 URLStreamHandler，而你无法直接调用解析逻辑——想可靠提取协议、主机、端口等字段，应该用 URI 类代替。
为什么不能依赖 URL 的 getHost()、getPort() 等方法
这些 getter 方法在 URL 未成功连接前可能返回空或默认值（如 getPort() 返回 -1），且对非法格式容忍度高，容易掩盖问题：
-
new URL("http://example.com:8080/path?x=1#frag")能构造成功，但若写成"http:///example.com"，getHost()可能返回空字符串而非抛异常 -
URL会尝试根据协议加载对应URLStreamHandler，若自定义协议未注册，getProtocol()可能正常，但后续解析行为不可控 - 不校验路径合法性：如
"http://a/b//c/./d/../e"不会自动归一化，getPath()返回原始字符串
用 URI 替代 URL 做结构化解析
URI 是纯语法解析器，不涉及网络连接，构造时即校验基本格式，各组件 getter 行为稳定可预期：
sc-java-to-ts-interface
下载
将后端 Java 接口文档转换为前端 TypeScript 类型定义（interface / type）。输入：飞书文档、Spring Boot 接口文档、Swagger/OpenAPI、手写 API 文档等。输出：包含请求参数与响应结果的 .md 文件，含完整 JSDoc 注释。触发关键词：Java 转 TS、接口转换、生成前端类型、接口文档转 TypeScript、DTO/VO/BO 转 interface、后端文档转前端类型、生成接口类型、类型定义生成。
URI uri = new URI("https://user:pass@host.example:8443/path/to/file?query=1#section");
System.out.println(uri.getScheme()); // https
System.out.println(uri.getHost()); // host.example
System.out.println(uri.getPort()); // 8443
System.out.println(uri.getPath()); // /path/to/file
System.out.println(uri.getQuery()); // query=1
System.out.println(uri.getFragment()); // section
System.out.println(uri.getUserInfo()); // user:pass
- 非法格式直接抛
URISyntaxException，比如new URI("http://[::1") - 支持相对 URI 解析：
new URI("base/path").resolve("sub/file")→base/sub/file - 若需转成
URL，调用uri.toURL()即可（但注意仍可能因协议 handler 缺失失败）
需要处理中文路径或特殊字符？必须先编码再构造
URI 构造器不自动编码，传入未编码的中文或空格会直接报错：
立即学习“Java免费学习笔记（深入）”；
- 错误写法：
new URI("http://example.com/你好")→URISyntaxException - 正确做法：对 path/query 等组件单独编码，再拼接：
URLEncoder.encode("你好", "UTF-8")得%E4%BD%A0%E5%A5%BD，再组合成http://example.com/%E4%BD%A0%E5%A5%BD - 更安全的方式是用
URI的多参构造器：new URI("http", "example.com", "/你好", null)会自动编码 path 部分
真正要解析 URL 字符串时，别碰 URL 的解析方法——它的设计目标是打开连接，不是拆解地址。用 URI，并注意编码时机，否则看似运行正常，遇到带空格、中文或奇怪端口的地址就突然崩掉。
