MalformedURLException本质是URL字符串解析失败，主因包括协议缺失、主机为空、含不可见字符等，须前置校验与精准恢复而非仅依赖try-catch。
Java中遇到MalformedURLException，本质是字符串无法被解析为合法的URL对象。它不是运行时偶然出错，而是构造过程严格校验失败的结果——协议缺失、主机为空、含不可见字符等，都会在new URL(String)这一步直接中断。处理的关键不在“兜底捕获”，而在于“前置拦截 + 精准恢复”。
协议缺失是最常见原因
报错信息常为no protocol，但问题未必出在没写http://。真实场景中更隐蔽：
- 用户输入
" example.com"——首尾空格导致协议识别失败 - 前端传参带BOM头（
\uFEFF），肉眼不可见却让解析器找不到冒号前的有效协议名 - 动态拼接时变量为空：
baseUrl + "/api"中baseUrl实际是""，结果变成"/api" - 协议拼写错误：
"htp://"、"https//"（少了一个冒号）
非法字符必须提前清理或编码
URL规范禁止空格、中文、制表符、换行符等直接出现。Java不会自动帮你转义，必须主动处理：
- 对原始字符串调用
trim()，消除首尾空白 - 含中文或特殊符号的路径/参数部分，用
URLEncoder.encode(value, "UTF-8")编码后再拼接 - 避免手动拼接查询参数，改用
UriComponentsBuilder（Spring）或java.net.URI构造后再转URL，它们对部分格式更宽容
别只靠try-catch，要分层防御
异常捕获是最后一道防线，不能替代校验逻辑：
立即学习“Java免费学习笔记（深入）”；
- 配置项或API入参，在进入业务逻辑前就做协议头检查：
url.startsWith("http://") || url.startsWith("https://") - 用正则粗筛（如
^(https?|ftp)://[^\s/$.?#].[^\s]*$），过滤明显非法输入 - 对关键URL字段（如支付网关地址），加白名单校验或强制协议补全逻辑：
if (!url.contains("://")) url = "https://" + url; - 日志中打印带边界符的原始串：
log.warn("Invalid URL: |{}|", urlString)，方便发现隐藏字符
URI比URL更适合作预处理
java.net.URI比URL更贴近RFC标准，解析容忍度更高，且不触发网络连接：
- 先用
new URI(string)尝试解析，它抛的是URISyntaxException，可单独处理 - 成功后调用
uri.toURL()获得URL对象，此时异常概率大幅降低 - URI还支持
normalize()、resolve()等方法，适合处理相对路径或路径合并场景
