怎样用 URL.canParse 在实例化前静默校验字符串是否为合法链接

URL.canParse 是 Chrome 94+ 和 Safari 16.4+ 支持的静态方法，用于安全校验 URL 字符串语法合法性，避免 new URL() 抛异常；它仅验证格式，不保证协议可用、域名有效或链接安全，需配合白名单、协议过滤等二次校验。

URL.canParse 是什么，它能解决哪些校验问题

URL.canParse 是 Chrome 94+ 和 Safari 16.4+ 原生支持的静态方法，用于在不抛出异常的前提下判断一个字符串是否符合 URL 语法规范。它比 new URL() 更轻量、更安全——后者在校验失败时会直接抛出 TypeError: Invalid URL，而 URL.canParse 只返回 true 或 false。

常见错误现象：用 new URL(input) 做校验却没加 try/catch，导致用户输入空格、http://、ftp:/ 等不完整字符串时页面 JS 崩溃。

注意：URL.canParse 只校验语法合法性，不保证协议可用、域名可解析或资源存在。比如 URL.canParse("<a href="https://www.php.cn/link/69e437ff7067a3c307417c25451f1344">https://www.php.cn/link/69e437ff7067a3c307417c25451f1344</a>") 返回 true，但 x 显然不是合法域名。

怎么用 URL.canParse 校验常见链接格式

实际使用时，需结合具体业务场景决定是否追加协议补全、是否允许相对路径等：

• 对用户输入的「完整链接」（如表单提交的跳转地址），直接传入原始字符串即可：URL.canParse(input)
• 若允许用户省略协议（如输入 example.com），需先手动补 https:// 再校验：URL.canParse(input.startsWith("http") ? input : "https://" + input)
• 不要对已知相对路径（如 /api/user）调用 URL.canParse，它会返回 false；相对路径应由业务逻辑单独处理
• 避免校验含空格或换行符的字符串，URL.canParse(" https ") 返回 false，建议先 .trim()

示例：

URL.canParse("https://a.co:8080/path?k=v#frag") // true  URL.canParse("http://") // false  URL.canParse("ftp://user:pass@host:21/path") // true（只要语法对，协议不限）  URL.canParse("javascript:alert(1)") // true（这是合法 URL scheme）

兼容性差怎么办：降级方案必须做这三件事

URL.canParse 在 Firefox 115 之前不支持，Node.js 也尚未内置（v20.10+ 才开始实验性支持）。降级时不能简单 fallback 到 new URL()，否则又回到抛异常的老路：

• 先检测方法是否存在：typeof URL.canParse === "function"
• 降级时用 try { new URL(input); return true; } catch { return false; }，而非直接 new URL(input) !== null（后者语法错就崩）
• 对于 SSR 或 Node.js 环境，若无法升级运行时，可引入轻量正则做基础格式筛查（如匹配 ^https?://[^s/$.?#].[^s]*$），但注意正则无法覆盖所有标准边缘 case，仅作粗筛

关键点：降级逻辑必须包裹在函数内复用，避免每个校验点都重复写 try/catch。

为什么不能只靠 URL.canParse 判断“用户能点开”

URL.canParse 的返回值为 true，只代表字符串能被解析为 URL 实例，不代表它安全、可用或符合业务规则：

• 它接受 data:、blob:、javascript: 等非导航型 scheme，但你的应用可能禁止跳转这类地址
• 它不校验域名黑名单（如 localhost、内网 IP）、也不识别钓鱼域名（如 paypa1.com）
• 它对编码不敏感：URL.canParse("<a href="https://www.php.cn/link/418f995ca45e4394daa4447bd637ec4d">https://www.php.cn/link/418f995ca45e4394daa4447bd637ec4d</a>") 是 true，但解码后才是真实 host

所以生产环境里，URL.canParse 最适合做第一道“语法门禁”，后续仍需结合白名单、协议过滤、甚至服务端二次校验。

真正容易被忽略的是：很多人把 URL.canParse 当成“防 XSS 链接校验工具”，但它对恶意 payload 完全不设防。需要拦截 javascript: 或 data:，得自己额外判断 input.startsWith("javascript:") || input.startsWith("data:")。