写正则匹配网址，正则址十个人能写出十一种结果。表达有人用一行搞定，式匹有人写了三百行还在漏 case。配网差别不在技术，正则址在于你有没有想清楚：你到底要匹配什么形态的表达网址。
先看一个最常见的式匹写法：
https?://[^\s]+这行代码能跑，但它粗糙得像个筛子。配网它会把 https://example.com。正则址 末尾的表达中文句号也吞进去，会把 https://example.com/path?式匹q=1&b=2" 里的引号算作网址的一部分。你拿它去处理一段真实文本，配网结果往往哭笑不得。正则址
问题的表达根源在于：网址不是一个有严格边界的字符串。RFC 3986 定义了 URI 的式匹通用语法，但现实世界里，网址出现在各种上下文里——HTML 属性、纯文本、Markdown 链接、聊天记录。每种场景的边界规则都不一样。你不可能用一个正则覆盖所有情况，但你可以根据具体场景写出足够好的那个。
拆开来看，网址到底长什么样
一个典型网址的骨架是这样的：协议 + 主机名 + 可选端口 + 路径 + 可选查询 + 可选片段。翻译成正则的构件：
(https?|ftp):// # 协议 ([\w-]+\.)+[\w-]+ # 域名 (:\d+)? # 端口 (/[^\s]*)? # 路径和后面所有东西这个版本比最开始那个强不少。它要求域名至少有一个点，端口必须是数字，路径以斜杠开头。但它仍然有漏洞：域名部分 [\w-]+ 不支持下划线以外的特殊字符，国际化域名（比如中文域名）直接歇菜。路径部分 [^\s]* 还是会吃掉右括号和引号。
我自己的做法是分两步走。先用一个宽松的正则把候选串捞出来，再用代码做后处理。正则负责“找到可能的网址”，代码负责“修剪边界”。比如匹配到 https://example.com/path).，检查末尾字符，如果是 ). 且左括号没有在网址中出现过，就砍掉。这个逻辑用正则写会变成灾难，用三行代码却清晰得很。
那些让人头疼的边界情况
括号是最烦人的。维基百科的网址里经常带括号，比如 https://en.wikipedia.org/wiki/Regex_(programming)。如果你简单地把右括号排除在字符类之外，这个网址就被截断了。正确的做法是允许括号，但在匹配结束后检查括号是否配对——不配对就回退。
中文标点也是重灾区。很多人写正则时只考虑英文语境，结果 [^\s]+ 把中文句号、逗号、顿号全吃进去。解决办法是在字符类里显式排除常见中文标点：
[^\s\u3002\uff0c\uff01\uff1f\uff1b\uff1a\u201c\u201d\u2018\u2019]+还有个冷门情况：网址末尾的斜杠。https://example.com/ 和 https://example.com 在大多数场景下等价，但正则匹配出来的结果不同。如果你要做去重或比较，得先归一化。
别追求完美，追求够用
我见过有人试图写一个“完美”的网址正则，最后搞出几百个字符，还附带一堆注释和条件分支。这种正则没人敢改，出问题也没人查得动。更务实的策略是：明确你的输入场景，针对这个场景写一个覆盖 95% 情况的正则，剩下的 5% 用代码兜底。
比如你只是要从一段聊天记录里提取网址，那 https?://[^\s<>"']+ 可能就够了。如果你要解析 HTML 里的链接，直接用 DOM 解析器，别跟正则较劲。正则不是万能锤，网址也不是钉子。
最后给一个我常用的版本，兼顾可读性和覆盖率：
https?://(?:[\w-]+\.)+[a-z]{ 2,}(?::\d+)?(?:/[^\s]*)?它不完美，但我知道它会在哪里失败，也知道怎么补。这比一个看起来完美但没人看得懂的正则强得多。