正则适合快速筛选和轻量校验，但不要把一个表达式写成无法维护的规则大全。实际使用时应配合样本文本测试边界、空值和异常输入。
几个常见示例
中国大陆手机号可用 ^1[3-9]\d{9}$ 做基础格式检查；邮箱可用 ^[^\s@]+@[^\s@]+\.[^\s@]+$ 做轻量判断；纯数字可用 ^\d+$；两位小数金额可用 ^\d+(?:\.\d{1,2})?$。
这些示例偏向实用而不是覆盖所有标准。邮箱、URL、身份证等复杂格式应根据业务规则再收紧，并准备足够的正反样本。
锚点和边界决定匹配范围
^ 和 $ 用来限制整段文本的开头和结尾。没有锚点时，表达式可能只匹配到字符串中的一小段，导致本该失败的输入通过校验。
在多行模式下，锚点含义可能随实现变化。处理日志或批量文本时，要确认工具或语言的正则选项是否开启了 multiline、global 或 ignore case。
转义和贪婪匹配最容易出错
点号、括号、问号、星号等字符在正则里有特殊含义。想匹配字面量点号时要写成 \.，在字符串代码里还可能需要再次转义。
.* 默认会尽可能多地匹配内容。解析 HTML、日志或括号内容时，优先使用更明确的字符范围，或用非贪婪写法减少误伤。
上线前用样本验证
至少准备正常样本、空字符串、前后空格、中文字符、超长输入和特殊符号。每改一次表达式，都用同一组样本重新测试。
正则适合第一道格式门槛。真正重要的数据还要在后端做二次校验，避免只依赖前端提示。
立即处理
使用相关工具
常见问题
关于这个问题
能不能用一个正则完整校验 URL？
可以写得很复杂，但维护成本高。多数场景建议用 URL 解析器或语言内置 URL API 做严格解析。
为什么复制到代码里后正则失效了？
常见原因是字符串转义层级不同，例如 \d 在某些语言字符串中需要写成 \\d。