.NET正则表达式含OR与字符范围时，为何匹配顺序会影响结果？

核心问题：*量词的0匹配特性 #

你遇到的问题本质是正则引擎的分支匹配规则，加上*量词允许匹配0个字符的特性导致的：

• 当使用[\x30-\x39]*|[\x61-\x7A]*时，正则引擎会按顺序优先尝试第一个分支：
  1. 字符串开头的数字段会被[\x30-\x39]*完整匹配，返回有效结果；
  2. 处理后续字母段时，第一个分支[\x30-\x39]*可以匹配0个字符（完全符合*的规则），引擎会直接返回这个空匹配，不会再尝试第二个字母分支。
• 反过来使用[\x61-\x7A]*|[\x30-\x39]*时，开头的数字段会触发第一个分支匹配0个字符，引擎直接返回空匹配；后续处理字母段时才会匹配到字母，整体表现就像只匹配到字母部分。

和012345|letters的区别 #

012345和letters都是非空的固定内容，正则引擎尝试分支时必须匹配到实际内容才会返回，不会出现空匹配的情况，因此能正常匹配到数字和字母两段内容。

解决办法 #

把量词*换成+（匹配1次或多次，不允许空匹配），正则表达式改成[\x30-\x39]+|[\x61-\x7A]+，全局匹配时就能同时捕获数字段和字母段，满足你分别替换的需求。

内容的提问来源于stack exchange，提问作者Kairei