正则匹配手机号、邮箱和 URL：不要只复制表达式，要知道边界

手机号、邮箱和 URL 看起来都有标准格式，但真实业务里边界很多。手机号要不要支持国外号码？邮箱要不要支持加号、子域名和新顶级域？URL 要不要支持 localhost、内网 IP、中文域名、端口和路径？如果一开始不说清楚，正则很容易写得又长又难维护，还不一定符合业务。

比较实用的原则是：前端做基础提示，后端做最终校验；注册登录场景尽量宽松，风控和结算场景可以更严格；需要长期维护的表达式要配测试样例，不要只留一行看不懂的符号。

这条表达式的意思是：以 1 开头，第二位是 3 到 9，后面 9 位数字，总共 11 位。它适合大多数表单基础校验，但并不能判断号码是否真实存在，也不能判断是否停机、携号转网或虚拟号段。涉及短信验证时，最终还是要以验证码流程为准。

如果输入里可能带空格、横杠或国家区号，不要急着把正则写得复杂。更稳的做法是先清洗文本，再校验。比如去掉空格和横杠，处理 +86 前缀，然后再用基础规则判断。

它不追求覆盖所有 RFC 细节，而是排除明显错误：不能有空格，必须有 @，域名里要有点。很多复杂邮箱正则看起来专业，但会误伤合法邮箱。真正要确认邮箱有效，还是要发验证邮件。

如果业务允许用户填 example.com 这种不带协议的地址，就不要强制 http 开头。相反，如果你要抓取网页或生成站外链接，就应该要求协议明确，避免相对路径和脚本伪协议混进来。

正则最怕只拿正确样例测试。手机号要测空格、短位数、长位数、+86、全角数字；邮箱要测没有 @、多个 @、中文、空格、加号；URL 要测没有协议、中文路径、带端口、带 QueryString、javascript: 开头。把这些样例放进正则工具里实时匹配，比直接上线后靠用户反馈靠谱。

如果一个表达式将来要多人维护，可以把规则拆开写在文档里：允许什么，不允许什么，为什么这样取舍。正则不是越复杂越好，能稳定解决当前问题才是好表达式。