产品代码（Product Code）在库存管理、电商系统、ERP 等业务场景中随处可见。它通常有固定的编码规则，比如长度固定、包含特定前缀、由字母和数字组成等。用正则表达式来验证产品代码是最常见的做法，但写得不够严谨的正则往往会放过非法输入，或者把合法输入误判为非法。这篇文章就来系统地讲一讲如何根据编码规则设计正则表达式，以及哪些错误最容易踩。
一、先搞清楚产品代码的编码规则
写正则之前，第一步永远是把编码规则梳理清楚，而不是急着动手拼表达式。很多验证漏洞的根源不在正则语法，而在于规则本身没定义清楚。你需要明确几个问题：代码总长度是固定的还是在一个范围内？允许哪些字符？有没有固定的前缀或后缀？中间有没有分隔符？分隔符位置是否固定？
举个例子，假设某系统的产品代码规则是：以大写字母 P 开头，后跟两位大写字母表示品类，再接六位数字，最后是一位校验数字或大写字母 X。那么合法样例就是 PAB123456X 这样的形式。规则明确之后，正则其实就已经呼之欲出了。
如果规则本身存在模糊地带，比如“校验位可能是字母也可能是数字，但不确定是哪些字母”，一定要先和业务方确认，否则正则写得再漂亮也白搭。正则只是规则的翻译器，翻译得再准，原文错了结果照样错。
二、常见产品代码格式的正则写法
1. 纯数字产品代码
最常见的场景，比如 8 位纯数字编码。写法非常直接：
// 匹配 8 位纯数字产品代码
var pattern = /^\d{8}$/;
console.log(pattern.test("12345678")); // true
console.log(pattern.test("1234567")); // false，长度不够
console.log(pattern.test("1234567a")); // false，含非数字字符这里的 ^ 和 $ 是锚点，分别表示字符串的开头和结尾。缺了它们，正则就变成“包含匹配”，abc12345678def 也会被判定为合法，这是新手最容易犯的错误之一。
2. 字母数字混合编码
比如 10 位编码，允许大写字母和数字混合：
// 匹配 10 位大写字母或数字组成的产品代码
var pattern = /^[A-Z0-9]{10}$/;
console.log(pattern.test("AB12CD34EF")); // true
console.log(pattern.test("ab12cd34ef")); // false，小写不合法注意 [A-Z0-9] 字符类中不要手滑加上空格，写成 [A-Z 0-9] 的话空格也会被当作合法字符。如果大小写都允许，写成 [A-Za-z0-9] 即可。
3. 带固定结构的复合编码
回到前面定义的规则：P + 两位品类字母 + 六位数字 + 一位校验字符（数字或 X）。对应的正则是：
// P + 两位大写品类码 + 六位数字 + 校验位(数字或X)
var pattern = /^P[A-Z]{2}\d{6}[0-9X]$/;
console.log(pattern.test("PAB123456X")); // true
console.log(pattern.test("PAB123456")); // false，缺少校验位
console.log(pattern.test("XAB1234567")); // false，前缀和校验位都不对这种分段式写法的可读性不错，每一段对应规则中的一部分，后期维护时一眼就能看出哪段对应哪个规则。如果编码规则复杂到有五六段，建议在代码里加注释说明每段的含义。
4. 带分隔符的编码
有些系统的产品代码形如 PRD-2024-0031，用连字符分段：
// 匹配 PRD-开头，中段4位数字，末段4位数字
var pattern = /^PRD-\d{4}-\d{4}$/;
console.log(pattern.test("PRD-2024-0031")); // true
console.log(pattern.test("PRD-2024-31")); // false，末段长度不足如果分隔符可能是连字符也可能是下划线，可以用字符类 [-_] 来匹配，但要注意规则必须明确两种分隔符能否混用。允许混用写成 [-_] 每段独立匹配即可；要求全文统一的话，正则做起来就比较别扭，通常更建议在代码层面先归一化再校验。
三、高频错误逐一解析
1. 忘记锚点导致部分匹配
这是发生率最高的错误。写了 \d{8} 却忘了 ^ 和 $，结果 用户输入abc12345678xyz 这种字符串也能通过验证，因为字符串中间确实包含连续 8 位数字。验证类的正则几乎永远应该成对使用锚点，除非你明确只想做搜索提取。
2. 量词使用 * 而不是 + 或具体次数
* 表示匹配零次或多次，意味着空字符串也可能通过验证。比如 /^[A-Z0-9]*$/ 会匹配空串，这在产品代码验证中几乎一定是错的。要么用 +（至少一次），要么直接写死次数 {8} 或范围 {6,12}。
3. 对 \d 的过度信任
在 JavaScript 中 \d 只匹配 0 到 9，但在某些语言（如 Python 3 处理 Unicode 字符串）中，\d 默认会匹配全角数字和其他 Unicode 数字字符。比如全角的 １２３４５６７８ 在 Python 里可能被 \d{8} 匹配通过。稳妥的做法是使用 ASCII 范围明确的字符类 [0-9]{8}，或者在正则编译时加上 ASCII 标志。
import re
# Python 中 \d 会匹配全角数字，需要留意
pattern1 = re.compile(r'^\d{8}$')
print(pattern1.match('１２３４５６７８')) # 能匹配，可能不符合预期
# 用显式字符类规避
pattern2 = re.compile(r'^[0-9]{8}$')
print(pattern2.match('１２３４５６７８')) # None4. 忽略首尾空白字符
用户从表格复制产品代码时，经常带入不可见的前后空格。字符串 " 12345678 " 不会被 ^\d{8}$ 匹配，看起来是正则挡住了非法输入，实际上是合法数据被误杀。更好的做法是在验证前先做 trim 处理：
function isValidProductCode(code) {
if (typeof code !== 'string') return false;
var trimmed = code.trim(); // 先去掉首尾空白
return /^P[A-Z]{2}\d{6}[0-9X]$/.test(trimmed);
}5. 特殊字符未转义
编码中如果包含 .、-、( 这类字符，要小心它们在正则中的特殊含义。尤其是点号，. 在正则里表示任意字符，/^V1.0$/ 实际上能匹配 V1X0。正确写法是转义：/^V1\.0$/。连字符在字符类内部也要注意位置，放在开头或结尾就没问题，放在中间可能被解释为范围，比如 [A-Z] 是范围而 [-AZ] 就是三个字面字符。
四、测试与维护建议
正则写完不等于完事，测试环节必不可少。建议为每条正则准备三组用例：明确合法的样例、明确非法的样例、以及边界模糊的样例（比如刚好卡在长度上限、校验位为 X、全角字符混入等）。边界用例最能暴露正则的漏洞。
另外一个实用建议是不要把正则散落在各个页面和接口里。产品代码规则一旦调整（比如从 8 位扩到 10 位），散落各处的正则很难一次改干净。更好的工程实践是把验证逻辑封装成独立的校验函数或常量，统一放在一个模块中，业务代码只调用这个入口。规则变更时只需要改一处，再跑一遍单测就能确认影响范围。
最后提醒一点：正则只能验证格式，不能验证有效性。格式正确的 PZZ999999X 未必是真实存在的产品。正则负责第一道关卡挡住明显的垃圾输入，真正的业务有效性还是要靠查询数据库或调用校验接口来完成，两层校验配合使用才是稳妥的方案。