在 WPS 里使用正则表达式这件事，我见过最典型的翻车现场不是“不会写表达式”，而是“表达式明明在别处能用，到了 WPS 里就废了”。有人把一份在 Python 里调好的正则直接塞进 WPS VBA，结果re.search没了，\d也变了；有人习惯在 WPS 表格里用REGEXREPLACE函数，却因为反斜杠少写了一层，匹配结果完全不对。问题通常不在正则本身，而在你脚下踩着的“正则引擎”根本不是同一个。
WPS 里至少有三类引擎：VBA 宏里用的 RegExp 对象、JS 宏里用的 JavaScript 正则表达式、还有新版表格内置正则函数里那套字符串正则方案。它们的语法有重叠，但差异点足以让你在调试上消耗一晚上。这篇文章想把这件事讲清楚：它们各自能做什么、容易踩哪些坑、以及怎么建立一套属于自己的“引擎识别—验证—落地”流程。看完之后，下次在 WPS 里碰见正则报错，你可以少走很多弯路。
1. 在 WPS 里写正则，不要只盯着表达式，先看清你用的是哪套引擎
1.1 为什么同一个 WPS 内部，会出现三套不同的正则规则
WPS 是一个体积庞大的办公软件，它包含文字、表格、演示，也开放了 VBA 宏、JS 宏、插件机制和内置函数。这些不同模块并不是同一个人、同一个团队、同一时间开发出来的，所以“正则支持”在内部天然分裂。
表格里的“查找替换”如果支持正则，它背后通常是软件底层 C++ 实现的某个正则库；VBA 宏里用的正则，是 WPS 为了兼容 Office 的 VBA 环境而实现的 COM 组件，常见形态是VBScript.RegExp，也就是 VBScript 正则引擎；JS 宏里写的正则，则是在 JavaScript 引擎里执行的，对标浏览器环境的 ECMAScript 正则。三者各自继承了不同生态的语法和限制。
这也是为什么网上搜“WPS 正则表达式”会得到互相矛盾的说法：不是别人写错了，是大家讨论的根本不是同一个入口。
1.2 三个最常见入口：VBA 宏、JS 宏、表格函数
先说清楚，你在 WPS 里和正则打交道的常见入口主要有三个：
- VBA 宏编辑器：开发工具 → VB 编辑器，写
Dim reg As Object、Set reg = CreateObject("VBScript.RegExp")这一套。 - JS 宏编辑器：开发工具 → WPS 宏编辑器（或 JS 宏），直接写
/pattern/flags这样的 JavaScript 正则字面量。 - 表格内置正则函数：在单元格里写类似
=REGEXREPLACE(A1, pattern, replacement)的公式，pattern 以字符串形式提供。
除了这三个，WPS 文字里可能还有“通配符”或“正则查找”，但那更接近一种受限的查找模式，不属于我们要重点对比的编程场景。
判断方法很简单：如果你敲进去的是对象、属性、Execute方法，那就是 VBA RegExp；如果写的是/正则/后面带g、i、m这类标志，那就是 JS；如果你在公式里写双引号字符串，那就是内置函数。
这里先抛一个判断：**你在 WPS 里遇到的大多数“正则灵异事件”，不是正则规则变了，而是引擎切换了。**所以后文的每一个引擎，我都会从“入口—写法—差异—避坑”四个角度展开。
2. WPS VBA 宏里的正则引擎：能用，但别拿现代正则特性去套
2.1 RegExp 对象的正确打开方式
在 WPS VBA 宏中使用正则，一般不是直接敲一个函数，而是先创建一个正则对象。常见写法是：
Dim reg As Object Set reg = CreateObject("VBScript.RegExp") reg.Pattern = "1[3-9]\d{9}" reg.Global = True reg.IgnoreCase = False Dim match As Object Set match = reg.Execute("我的手机号是13800138000，备用号是13900139000") Dim m As Object For Each m In match Debug.Print m.Value Next这里有几个关键点：
Object类型而不是强类型RegExp，是为了兼容不同 WPS 和 Office 的引用差异。Pattern里存字符串，不需要像 JS 那样加斜杠。Execute返回一个集合，遍历时要用For Each。- 如果没有匹配到，
Execute返回空集合，此时match.Count = 0，不需要Nothing判断成惯例。
2.2 几个标志位和换行匹配的经典差异
VBScript 正则引擎的属性不算多，最常见的是Global、IgnoreCase、MultiLine。
Global控制是否匹配所有结果。如果不设，Execute只会返回第一个匹配；设为True才返回全部。IgnoreCase控制大小写不敏感。MultiLine决定^和$是否按行匹配。
还有一个非常容易被忽略的点：**VBScript 正则在默认情况下，.是不匹配换行符的。**而在“正则引擎”里，改变这个行为的方式因语言而异。JavaScript 可以用s标志；Python 可以用re.DOTALL；但在 VBScript RegExp 里，没有对应的属性或标志。
所以如果你要从一段包含换行的文本里跨行匹配，不能指望.。一个通用的做法是用[\s\S]代替任意字符。
例如：
reg.Pattern = "[\s\S]*?END"而不是：
reg.Pattern = ".*?END"注意这一点非常容易在你切换到 VBA 时“水土不服”。因为很多人平时在 JS 里用.用习惯了，到 VBA 里发现匹配不到，第一反应是调整表达式，其实问题出在引擎对换行的处理策略上。
2.3 在 VBA 里最容易踩到的“反向替换”坑
VBA 里用正则做替换时，很多人会写成：
reg.Replace("电话是13800138000", "\1")这在很多语言里表示“第一个捕获组”，但在 VBScript RegExp 中，替换串里的反向引用不是\1，而是$1。正确写法是：
reg.Replace("电话是13800138000", "$1")如果写成\1，VBA 不会报错，但结果不会按你预想的替换。它会把\1当普通字符插入到结果里。这个坑的隐蔽性在于：表达式本身没有语法错误，只有输出结果不符合预期。调试时很容易误判为“表达式没匹配上”，实际上匹配已经成功了，是替换文本写错了。
所以如果你从 Python、Java、JavaScript 等语言迁移到 WPS VBA 写Replace，请第一时间检查替换参数里用的是$1还是\1。
VBA 正则还有一个需要小心的地方：它不支持一些现代高级语法，比如后行断言(?<=...)、命名捕获组(?<name>...)这类特性，在不同环境和版本中支持度差异很大。我的建议是：在 WPS VBA 里，尽量使用最基础的分组、字符类、量词和前瞻，不要把表达式写得过于“时髦”。
3. WPS JS 宏里的正则引擎：最接近现代正则，但也要做兼容测试
3.1 JS 正则的入口和字面量写法
WPS 的 JS 宏是 WPS 特色功能之一，它允许用户用 JavaScript 脚本操作 WPS 文档。既然是在 JavaScript 环境里，正则表达式就使用 ECMAScript 标准那一套。
最基本的用法是字面量：
var reg = /1[3-9]\d{9}/g; var text = "电话是13800138000"; var result = text.match(reg); console.log(result);也可以是构造函数：
var reg = new RegExp("1[3-9]\\d{9}", "g");这里有一个常见分歧：字面量里的\d直接写\d，而在字符串写法的构造函数里，反斜杠需要转义成\\d，因为字符串解析还会剥掉一层反斜杠。
3.2 捕获组替换：从 $1 到 (p1)=>
JS 正则替换支持$1形式的反向引用，也支持回调函数。VBA 里用$1只能拿到捕获组内容，而在 JS 里，你可以在replace的回调函数中对捕获组做处理：
var text = "2024-01-15"; var converted = text.replace(/(\d{4})-(\d{2})-(\d{2})/, function(_, y, m, d) { return d + "/" + m + "/" + y; }); console.log(converted); // 15/01/2024这种能力比 VBA 灵活很多。但问题也在这里：WPS JS 宏所依赖的 JavaScript 引擎，并不一定和最新版浏览器完全同步。也就是说，你在 Node.js 或浏览器里试好的正则，到了 WPS JS 宏环境里，某些新特性可能会失效。
3.3 在 JS 宏里建议先做版本探测
我一般会在正式写表达式之前，先做一个简单的“能力探测”，把当前 WPS JS 宏环境支持哪些正则会话特性探出来。比如：
function detectRegexSupport() { var results = {}; results.lookbehind = (function() { try { return new RegExp("(?<=a)b").test("ab"); } catch (e) { return false; } })(); results.namedGroup = (function() { try { return new RegExp("(?<x>a)").exec("a").groups.x === "a"; } catch (e) { return false; } })(); results.dotAll = (function() { try { return new RegExp("a.s", "s").test("a\ns"); } catch (e) { return false; } })(); return results; }运行一次，把结果记录下来。比自己事后猜要高效得多。
这里的判断是：**JS 宏是 WPS 三种正则环境里“最接近现代正则”的，但正是因为它接近现代，反而容易让你忽略版本边界。**你不需要刻意使用冷门语法，但如果要用，最好先探测，再大批量套用。
4. WPS 表格内置正则函数：表面上简单，实际上转义和标志位到处是坑
4.1 函数长什么样，怎么快速判断你的版本是否支持
新版 WPS 表格开始提供一些以REGEX开头的函数，比如REGEXTEST、REGEXREPLACE、REGEXEXTRACT。它们和 Excel 365 里的正则函数思路类似，但实现细节不一定完全一致。
一个典型用法是：
=REGEXEXTRACT(A1, "\d+")这种函数的好处是：不用打开宏编辑器，就能在单元格里完成提取、匹配、替换操作。
但一个现实问题是：不同版本、不同平台（Windows/Mac/Linux）的 WPS 对这几个函数的支持情况很不一样。你最好不要直接假设“所有同事的 WPS 都有这个函数”。如果公式返回#NAME?错误，那通常说明当前版本没有这个函数，或者函数名有差异。
我的建议是：先在一个空白单元格里手敲函数名，看输入时是否出现函数提示。如果没有提示，可以再去“公式”菜单里找函数列表，搜一下regex。不要盲目大批量使用。
4.2 字符串里的反斜杠：写一遍，走进引擎又是一遍
内置正则函数有一个极其容易踩坑的地方：pattern 是以字符串参数传入的，字符串本身会执行一层转义。
比如你要匹配一个数字，在正则引擎里写\d，但在函数公式里，你输入到单元格中的字符串如果是"\d"，实际的 pattern 不一定是\d。要具体看函数内部是“原样接收字符串”还是“经过了字符串转义处理”。
更常见的情况是：你要匹配点号.，正则里写\.，在公式里可能得写成"\\."，因为字符串层先剥掉一层，剩下\.才能传给引擎。
这带来的问题是：公式栏里显示的表达式和引擎真正接收到的表达式并不一样。排查时你不能只看公式栏，还要推演字符串转义后的值。
通常我会先在测试区域写一个非常简单的匹配，比如：
=REGEXREPLACE("a.b", ".", "-") =REGEXREPLACE("a.b", "\.", "-") =REGEXREPLACE("a.b", "\\.", "-")三个结果对照，就能判断当前 WPS 版本里，反斜杠到底被剥了几层。这种做法看起来笨，但能很快确认环境行为。
4.3 函数正则与宏正则在行为上的差异
内置函数正则和宏正则还有一个天然差异：宏正则可以反复修改代码、调试输出，而函数正则在单元格里一旦写完，调试信息很少。你可能只知道“结果不对”，却很难知道引擎内部是匹配不上，还是替换文本有问题，或者是转义错了。
另外，函数正则在处理空值时也有坑。比如需要匹配的源单元格是空字符串，函数可能返回空值，也可能返回#VALUE!，具体取决于实现。所以我在写公式时，通常会先用IF或IFERROR包一层：
=IFERROR(REGEXREPLACE(A1, "\d+", "#"), A1)既不会影响正文，还能在出错时保留原值，便于定位问题。
5. 一套减少引擎冲突的落地流程：识别→试→记→批
5.1 引擎识别四问
面对一个正则需求，不要急着写表达式，先回答四个问题：
- 我在哪个模块用？单元格函数、VBA 宏、JS 宏，还是查找替换？
- 我使用的数据入口是对象还是字符串？RegExp 对象用
Pattern属性，JS 用字面量或构造函数，函数用字符串参数。 - 我需要哪些标志位？VBA 用
Global/IgnoreCase/MultiLine，JS 用g/i/m/s/u，函数只能随着字符串参数走。 - 替换文本里用
$1还是\\1？不同引擎不一样，先确定这个，能省很多时间。
这四个问题清楚了，就能确定表达式大框架，不用来回试错。
5.2 最小用例验证表
在开始写完整逻辑之前，先准备一个最小验证用例。我一般会在每个引擎里都跑这几种模式：
- 纯数字匹配：
\d+或[0-9]+ - 边界匹配：
^、$、\b - 点号匹配：
.是否匹配换行 - 捕获组替换：
$1或\1 - 转义点号：
\.在不同字符串里怎么写
把结果记录下来，形成自己的对照表。之后所有复杂表达式，都以这张表为基础，遇到不确定的地方，回去查表确认。
5.3 建立个人正则兼容清单
长期使用 WPS 的人，最好维护一个自己的“WPS 正则兼容清单”。表格结构可以很简单：
| 入口 | 正则写法 | 是否支持 | 亮点 | 注意点 |
|---|---|---|---|---|
| VBA RegExp | \d | 是 | 基础字符类稳定 | 替换要用$1 |
| VBA RegExp | (?<=a)b | 不同版本差异大 | 建议先用变量测试 | 不要在生产代码里依赖 |
| JS宏 | \d+ | 是 | 习惯与现代 JS 接近 | 探测后行断言 |
| JS宏 | (?<name>x) | 待探测 | 命名组好用 | 确认你的 WPS 版本 |
| 表格函数 | \d+ | 是 | 无代码门槛 | 注意字符串转义 |
这张清单要伴随你的实际测试不断更新。它不需要很复杂，但能避免你反复踩同一个坑。
5.4 什么时候不该用正则
正则不是万能的。在 WPS 里，遇到以下情况我会建议优先考虑其他方案：
- 数据量非常大，且只做一次性的批量替换，性能敏感时，优先用单元格函数或查找替换，而不是 VBA 循环。
- 文本结构非常不规则、嵌套过多时，不要试图写一个能通吃所有情况的正则，建议分段或改用脚本逻辑。
- 需要长期维护，而代码里只有正则没有注释时，下次接手的同事很难维护。至少要在代码旁注明“这里匹配的是什么”。
6. 正则报错排查链路：从现象到根因，按这个顺序来
6.1 先看现象，再猜原因
在 WPS 里正则出问题，现象通常集中在这几类：
- 报错：比如 VBA 里
Invalid procedure call or argument，JS 里SyntaxError: Invalid regular expression，函数里#VALUE!或#NAME?。 - 不报错，但匹配不到：最常见。表达式看起来没问题，却没有结果。
- 匹配到了，但替换文本不对：多出现在
$1和\1混用场景。 - 结果不稳定：同一个表达式在不同电脑、不同 WPS 版本里表现不一样。
看到现象后，先不要直接改表达式。确认一下当前所处引擎，比任何调试技巧都重要。
6.2 输入、环境、参数、工具边界四级排查
我把排查顺序固定为四级：
- 输入：先确认待匹配文本是真的长那样，还是有多余的空格、换行、不可见字符。可以用
Len()、codePointAt或LEN函数辅助检查。 - 环境：当前是在 VBA 宏、JS 宏还是表格函数里？同一表达式换到另一环境，可能表现完全不同。
- 参数：
Global、IgnoreCase、MultiLine、flags是否设得对？替换文本里是$1还是\\1？字符串模式中反斜杠是否多写或少写了一层？ - 工具边界：当前 WPS 版本是否支持这个语法？是否缺少某个内置函数？是不是需要升级版本或换到另一个入口？
只要按这个顺序走，大多数问题都能定位到“某一层”上，而不是无头苍蝇式地试表达式。
6.3 兜底手段：用日志或 MsgBox 把真实模式打出来
最后的兜底手段，是把引擎真正解析到的模式打印出来。VBA 里可以这样：
Debug.Print reg.PatternJS 宏里可以：
console.log(reg.source);单元格函数里没办法直接打印，但你可以用REGEXREPLACE的极端用例来反向验证。
很多细节问题，比如转义次数不对、模式里多了空格、反斜杠被吞了，只要把真实模式打出来，一眼就能看出来。这个习惯到了 WPS 里同样管用。
WPS 中正则表达式的难点，从来不是“无从下手”，而是“入口太多、引擎不统一”。如果你每次都只是从互联网上复制一段正则表达式，却不去确认它适用于哪个环境，那大概率会继续在报错和错误结果之间来回折腾。反过来，当你养成了“先用四个问题识别引擎、再用最小用例验证环境、最后把结果记到兼容清单里”的习惯，WPS 正则就不再是玄学，而是一个完全可控的普通工具。下次再遇到“表达式莫名其妙失效”，别急着怀疑正则，先低头看看脚下。
