MalformedURLException 通常不是运行时该捕获的异常
这个异常是 java.net.URL 构造函数抛出的检查型异常，本质是「你传了个明显非法的字符串给它」——比如协议缺省、冒号位置错、空字符串、含非法字符等。它反映的是代码逻辑问题，不是网络或用户输入的偶然错误。
常见错误现象：new URL("http//example.com")（少了一个冒号）、new URL("ftp:/path")（协议后格式不合法）、new URL(" ")（空白字符串）。
实操建议：
- 不要在运行时靠
try-catch挡住MalformedURLException来“兜底”，这等于把构造逻辑错误藏起来 - 如果 URL 来自配置文件或常量，直接用 IDE 或单元测试校验；来自用户输入或外部 API，则必须先做预处理，再进
URL构造 - 别把
URL当作通用字符串解析工具——它只认 RFC 1738 定义的绝对 URL 格式，不支持相对路径、不带协议的域名等“人眼可读但机器不认”的写法
用 URI 替代 URL 做初步合法性校验
java.net.URI 比 URL 更宽松、更专注语法检查，且构造时不抛检查型异常（只抛 URISyntaxException，是运行时异常），更适合做前置校验。
立即学习“Java免费学习笔记（深入）”；
使用场景：接收用户提交的链接、解析配置项、清洗日志中的 URL 字符串。
参数差异：URI 允许不带协议（如 new URI("example.com/path")）、允许只含路径、能更好区分 scheme/authority/path；而 URL 强制要求协议 + 主机（或至少符合绝对 URL 结构）。
实操建议：
- 先用
new URI(inputString)尝试构造，捕获URISyntaxException判断是否基础格式合法 - 若需后续发起网络请求，再用
uri.toURL()转成URL——这时失败概率极低，因为URI已筛掉大部分非法输入 - 注意：
URI不校验协议是否存在（比如foo://bar也能过），也不校验主机名是否 DNS 可解析，它只管语法
真正需要校验的其实是协议、主机和路径语义
语法合法 ≠ 可用。比如 https://[::1]:65536/path 是合法 URI，但端口号超限；http://localhost:8080/..%2fetc%2fpasswd 语法合法，但存在路径遍历风险。
性能 / 兼容性影响：全量做 DNS 解析或 HTTP HEAD 请求来验证可用性，会显著拖慢流程，且不可靠（防火墙、临时不可达等）。
实操建议：
- 协议白名单控制：
if (!"http".equals(uri.getScheme()) && !"https".equals(uri.getScheme()))，避免执行危险协议（如file、jar） - 主机约束：用
uri.getHost()提取后做简单规则判断（如非空、不含空格、长度合理），必要时用正则粗筛 IP 或域名格式 - 路径清理：调用
uri.normalize().getPath()再检查是否包含".."或空字节等敏感模式，尤其当你要拼接本地文件路径时
Spring 和 OkHttp 等框架里怎么绕过手动校验
如果你用的是 Spring WebMVC 或 WebClient，@RequestParam 或 @PathVariable 接收 URL 字符串时，默认不会自动转成 URL 对象，也就不会触发 MalformedURLException ——它只是个 String。真正出问题是在你显式调用 new URL(...) 的那一刻。
OkHttp 的 Request.Builder.url(String) 内部用的就是 HttpUrl.parse()，它返回 null 表示解析失败，而不是抛异常，比原生 URL 更适合用户输入场景。
实操建议：
- 用 OkHttp？直接信
HttpUrl.parse(input)的返回值，null就拒绝 - 用 Spring？别在 Controller 里立刻
new URL(param)，先存为String，进 service 层再按需解析 + 校验 - 用 Jackson 反序列化 JSON 中的 URL 字段？加
@JsonCreator自定义构造逻辑，内部用URI校验后再转URL，避免反序列化失败打断整个对象构建
最易被忽略的一点：很多人以为校验了 URL 就安全了，其实 URL 对象本身会自动 decode 某些百分号编码，比如 http://x.com/%61%62%63 构造后 getPath() 返回 "/abc"，但原始字符串里的编码可能就是攻击载荷。校验必须在 decode 前做，或者明确你校验的是解码后的语义。
