URL.canParse：实例化前静默校验链接合法性

在前端开发中，处理用户输入的链接是一个常见但容易出错的场景。直接使用 new URL() 进行校验？一旦用户输入包含空格或协议不完整，页面脚本可能会直接崩溃，抛出 TypeError: Invalid URL 错误。

是否存在更优雅、更安全的方式？答案是否定的。从 Chrome 94 和 Safari 16.4 开始，浏览器原生提供了静态方法 URL.canParse。它的核心价值在于，在不抛出异常的前提下，静默判断字符串是否符合 URL 语法规范。

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

简单来说，URL.canParse 是一个语法检查器。它接收一个字符串，返回布尔值：true 表示该字符串能被解析为合法 URL 结构，false 表示语法存在问题。

它的最大优势在于“静默”处理。回想一下，如果使用 new URL('http://') 或 new URL(' https://example.com ')，程序会立即中断并报错。这在表单校验等交互场景中体验极差。而 URL.canParse 遇到这些情况只会返回 false，让开发者有机会向用户展示友好提示，而非控制台错误。

然而，一个重要概念必须厘清：语法合法不等于链接可用。 URL.canParse 仅负责检查格式，例如协议头、冒号、双斜杠、主机名、路径等组成部分是否符合规范。它不检查域名是否真实存在、协议是否被浏览器支持，也不评估链接安全性。

举例来说，URL.canParse("https://x") 会返回 true，因为 “https://x” 语法完全正确。但显然，“x” 并非有效域名。同样，字符串 ja vascript:alert(1) 也会被认为是合法，因为它符合 “scheme:path” 的 URL 结构。

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

在实际业务中，用户输入五花八门。直接调用 URL.canParse(input) 可能不够，需要根据场景进行预处理。

首先，对于用户明确需要输入完整链接的场景（如“个人博客地址”），直接校验即可。但如果设计允许用户偷懒，只输入 example.com 这类域名，就需要先手动补上协议头（通常是 https://）再进行校验。

另一个常见误区是用它校验相对路径。像 /api/user 或 ./assets/logo.png 这样的字符串，URL.canParse 会返回 false，因为它们缺少协议和主机名。相对路径的合法性应由路由逻辑或资源加载逻辑单独判断，不属于 URL 语法校验范畴。

最后，需要处理用户输入中可能存在的首尾空格。虽然 URL.canParse(" https://example.com ") 也会返回 false，但更好的做法是先使用 .trim() 方法清理，避免因无心空格导致校验失败。

以下例子能帮助你更好理解其行为边界：

URL.canParse("https://a.co:8080/pathk=v#frag") // true，标准格式
URL.canParse("http://") // false，缺少主机名
URL.canParse("ftp://user:pass@host:21/path") // true，语法正确即可，不关心协议是否常用
URL.canParse("ja vascript:alert(1)") // true，这是一个合法的 URL Scheme

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

目前，URL.canParse 的浏览器支持尚不全面，Firefox 在 115 版本之前不支持，Node.js 环境从 v20.10 才开始实验性支持。因此，健壮的降级方案必不可少。

降级核心思路是回归传统 try...catch 包裹 new URL() 的方式。但关键在于，不能在 URL.canParse 不被支持时直接调用 new URL(input)，否则又会回到抛出异常的老路。

正确做法分三步：

1. 能力检测：先判断当前环境是否支持 URL.canParse。
2. 安全降级：若不支持，则在 try...catch 块中实例化 new URL(input)，根据是否抛出异常返回 true 或 false。
3. 封装复用：务必将此逻辑封装成独立校验函数，避免在代码各处重复编写 try...catch，这是代码可维护性的基本要求。

对于某些无法升级运行时的服务端渲染 (SSR) 或老旧 Node.js 环境，如果连 new URL() 都不稳定，可考虑用轻量正则表达式做基础格式筛查（例如粗略匹配 ^https://[^\s/$.#].[^\s]*$）。但必须清醒认识到，正则几乎无法 100% 覆盖 URL 标准所有复杂边缘情况，只能作为权宜之计的粗筛过滤器。

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

这是理解 URL.canParse 定位最重要的一环。它返回 true 仅表示字符串“像”一个 URL，绝不代表安全、可用或符合业务规则。

它至少存在以下“盲区”：

• 协议过滤：它会放行 ja vascript:、data:、blob: 等 scheme。若应用涉及链接跳转，这些协议可能成为安全漏洞（如 XSS）入口，必须额外拦截。
• 域名安全：它不区分 google.com 和 g00gle.com（钓鱼域名），也不关心 localhost 或内网 IP 地址（如 192.168.1.1）是否应被禁止访问。这需要结合业务域名的白名单或黑名单来校验。
• 编码问题：它对 URL 编码透明。例如 https://%77%77%77%2e%65%78%61%6d%70%6c%65%2e%63%6f%6d 能通过校验，但需解码后才能得到真实 host（www.example.com）。如果要做域名匹配，必须先解码。

因此，在生产环境中，URL.canParse 最合适的角色是担任第一道“语法门卫”。它的任务是快速筛掉连格式都不对的无效字符串。通过此关后，链接还需经过协议白名单、域名校验甚至服务端二次安全审查等多重关卡，才能最终被判定为“可用”。

一句话总结：将其视为语法校验器，而非安全卫士。指望它防御 XSS 远远不够，对于 ja vascript: 或 data: 等危险协议，必须在业务逻辑层自行进行明确判断和过滤。