.任意字符（不含换行）\d数字 0-9\D非数字\w单词字符\W非单词字符\s空白字符\S非空白[abc]匹配 a、b 或 c[^abc]排除 a、b、c[a-z]a 到 z 范围^字符串开始$字符串结尾\b单词边界\B非单词边界*零个或多个+一个或多个?零个或一个{n}恰好 n 次{n,}n 个或更多{n,m}n 到 m 次*?懒惰零个或多个+?懒惰一个或多个(abc)捕获组(?:abc)非捕获组(?<name>abc)命名捕获组(?=abc)正向先行(?!abc)负向先行(?<=abc)正向后行(?<!abc)负向后行\1反向引用第 1 组g全局匹配i不区分大小写m多行模式s让 . 匹配换行uUnicode 模式y粘性匹配 (y 标志)^\d{4}-\d{2}-\d{2}$ISO 日期^[\w.+-]+@[\w-]+\.[\w.-]+$简单邮箱^https?:\/\/\S+$HTTP URL^\d{3}-\d{2}-\d{4}$美国社保号^#?([a-f\d]{6}|[a-f\d]{3})$十六进制颜色^\+?[1-9]\d{1,14}$E.164 电话关于 正则速查表
正则速查表汇集最常用的正则表达式片段与语法要点，从锚点、字符类、分组与反向引用，到贪婪懒惰匹配、前瞻后顾与常用的邮箱手机校验模式，一应俱全。每条都附带说明与可复制的示例，新手能快速套用，老手也能随时回顾冷门写法。页面按主题分组并支持浏览器内检索，离线也能查阅，省去反复翻文档。对做表单校验、日志提取或文本清洗的开发者，是一个写正则时随手确认的实用备忘，也适合作为团队内部统一正则写法的参考索引，减少每个人各写一套带来的维护成本。在 code review 时快速对照既有模式是否可复用，能减少团队内部正则写法分裂；页面按主题分组支持浏览器内检索且离线可查，对新手快速套用、老手回顾冷门写法都很方便，也适合作为统一正则写法的参考索引沉淀到团队知识库里反复使用。
片段与「可直接使用的表达式」之间隔着一层约束确认，这是使用速查表的前提。表里的片段通常只表达「匹配什么形态」，省略了锚点、边界与排除条件，因此直接用于校验往往过于宽松。正确用法是把它当作起点，再补上「从头到尾」的锚定、明确允许的字符范围，以及明确的长度限制，最后用反例验证。
不同引擎的差异在照搬时最容易暴露。点号是否匹配换行、是否支持后顾、字符类简写的含义、以及是否默认全局匹配，各家默认行为不同，同一个表达式换个语言可能结果完全不同。因此跨语言搬运片段时应先确认目标引擎的方言，逐条核对边界行为，而不是假定语法相通。
性能是一个常被忽略的维度。能匹配的表达式未必能高效匹配：嵌套量词在长串不匹配时会产生指数级的尝试次数，几百个字符就能把处理进程占满。因此拿到片段后应想一下它在最坏输入上的行为，尤其是用于处理用户提交的任意文本时，必要时改用更明确的字符类或加上长度上限。
与「用解析器」的分工也值得明确：正则擅长处理线性、规则简单的文本，不擅长嵌套结构。试图用正则解析标记语言或数据格式，短期看似可行，长期必然在注释、转义与嵌套上出问题。遇到这类需求应改用现成的解析库，把正则留给它真正擅长的字段提取与格式校验。
最后，把速查表里的片段纳入项目规范是提升一致性的有效做法：约定好邮箱、手机号、日期的校验表达式并集中维护，避免每个模块各写一份略有差异的版本。集中之后，规则变更只需改一处，评审时也有明确依据，比散落各处的自写正则更容易保证质量。
还有一个前提与维护有关：正则表达式一旦进入代码就很少有人愿意改动，因为它看起来难以理解。缓解办法是给每个非平凡表达式配一行注释说明它要匹配什么、以及为什么排除某些情况，并配一组反例测试。这两项的成本很低，却让半年后的修改者能判断改动是否安全。
实现原理
速查片段为便于理解通常省略锚点与边界条件，因此不能直接用于生产：只匹配数字的片段放到长文本里会命中任意位置的数字，邮箱与手机号片段也只做形态匹配。使用前必须回答两个问题——要匹配什么、不要匹配什么，并准备反例测试。
把 \d+ 用于校验「整串是数字」会匹配 "abc123" ——需要加上首尾锚点：^\d+$使用方法
- 打开「正则速查表」
- 粘贴待处理的文本
- 根据需要调整输出选项
- 点击「处理」按钮，结果实时显示
- 复制或导出结果
使用场景
- 语法回忆 — 忘了"非贪婪"怎么写时，秒查 .*? 与 .+? 的用法。
- 断言查阅 — 对照前瞻、后顾的写法，正确写出仅匹配特定上下文的规则。
- 字符类参考 — 查 \d、\s、\b 等转义含义，避免把 \b 误用在字符集里。
- 面试备考 — 系统复习正则各类语法，应对笔试与技术面试中的题目。
- 教学演示 — 给团队新人讲解正则时，用速查表作为统一参考资料。
常见问题
速查表针对哪种正则方言？
以最通用的语法为主，贴近 JavaScript（ECMAScript）正则，多数规则也适用于 PCRE、Python 等，个别细节各引擎略有差异。
\b 在不同语言里一致吗？
单词边界 \b 的基本含义一致，但对 Unicode 字符（如中文）的边界判定，不同引擎处理可能不同，需实测。
能在这里直接测试我的正则吗？
本页是语法参考，若要边写边验证匹配结果，请使用本站的正则测试类工具实时调试。
贪婪和非贪婪有什么区别？
贪婪量词（如 *）尽量多匹配，非贪婪（如 *?）尽量少匹配；处理 HTML 标签等成对结构时常用非贪婪避免越界。
为什么字符串里的反斜杠要写两个？
在多数编程语言的字符串里，反斜杠本身要转义，所以正则的 \d 在代码字符串中常写作两个反斜杠加 d，使用时注意区分。
直接复制速查表里的表达式能用于生产吗？
不应直接使用。速查片段为便于理解通常省略锚点与边界条件，例如只匹配数字的片段放到长文本里会命中任意位置的数字；邮箱与手机号这类片段也只做形态匹配，不保证真实存在。使用前应先明确「要匹配什么、不要匹配什么」，补齐锚点并准备反例测试，再投入生产。
同一个表达式在不同语言里结果不同，是什么原因？
各语言引擎的默认行为并不一致：点号是否匹配换行、是否支持后顾、字符类的简写含义、以及是否默认全局匹配都有差异。跨语言搬运时应先确认目标引擎的方言，逐条核对边界行为，而不是假定语法相通；把关键表达式连同测试用例一起记录，能显著降低迁移风险。
正则里的 . 能匹配换行符吗？
默认不能，. 匹配除换行外的任意字符。要跨行匹配需要启用 s 标志（dotall），或者用 [\s\S] 代替 .。处理多行文本时这是最常见的「明明写了 .* 却没匹配上」的原因。