@pytest.mark.parametrize是Pytest中实现正则边界测试的最佳方式，通过将pattern（预编译）、text、expected及ids打包为独立用例，可避免重复断言、提升可维护性与失败定位精度，并需注意fullmatch语义、Unicode标志及regex库一致性。
用 pytest 参数化测试多个正则边界输入
直接写多个 assert re.match(...) 会重复、难维护。用 @pytest.mark.parametrize 把输入、期望结果和描述打包成用例最稳妥。
常见错误是把正则模式写死在测试函数里，导致改一个 pattern 就得改一堆断言；或者把所有边界 case 塞进一个测试函数，失败时看不出具体哪条出问题。
- 每个测试用例应包含：
pattern（正则）、text（待匹配字符串）、expected（True或False，或预期的re.Match属性如.group(0)） - 用
ids参数给每条用例起简短名字，比如"empty_string"或"trailing_newline"，失败时一眼定位 - 避免在参数化中传入未编译的 pattern 字符串——每次调用都重新编译，影响性能；提前用
re.compile()编译好再传入
import re
import pytest
<p>PATTERN = re.compile(r'^\d{3}-\d{2}-\d{4}$') # SSN 格式</p><p>@pytest.mark.parametrize(
"text,expected",
[
("123-45-6789", True),
("", False),
("123-45-678", False),
("123-45-6789\n", False), # 注意换行符
(" 123-45-6789 ", False), # 注意空格
],
ids=["valid", "empty", "short", "trailing_nl", "spaced"]
)
def test_ssn_pattern(text, expected):
assert bool(PATTERN.fullmatch(text)) == expected区分 re.match、re.fullmatch 和 re.search 的语义差异
很多边界问题其实不是正则写错了，而是选错了匹配函数。比如用 re.match 测试带前导空格的输入，它只从开头匹配，但你实际想验证整串是否合规——这时该用 re.fullmatch。
立即学习“Python免费学习笔记（深入）”；
典型误用场景：校验用户输入格式（如邮箱、身份证号）时，漏掉 ^ 和 $ 锚点，又没用 fullmatch，导致 "abc@example.com junk" 这种非法输入被误判为合法。
-
re.match(pattern, s)：仅检查s开头是否匹配，等价于re.search(f'^{pattern}', s) -
re.fullmatch(pattern, s)：要求整个s完全匹配，等价于re.match(f'^{pattern}$', s)，推荐用于格式校验 -
re.search(pattern, s)：只要子串匹配就返回，适合日志提取等场景，但不适合“是否符合格式”类断言
测试 Unicode、空字节、零宽断言等易错边界
正则在非 ASCII 场景下容易翻车：中文字符、组合字符、BOM、\x00、零宽空格（\u200b）都可能让 re.match 行为突变，尤其当 pattern 没加 re.UNICODE 标志时。
常见坑：用 r'\w+' 匹配中文用户名，结果返回 None；或用 r'^[a-zA-Z0-9_]+$' 校验昵称，却放过了含零宽空格的“看起来合法”的字符串。
- 对含 Unicode 的 pattern，显式传
flags=re.UNICODE（Python 3 默认开启，但显式写出更安全） - 用
bytes类型测试空字节：re.match(rb'hello', b'hello\x00world')可能意外成功，因为\x00不终止字符串匹配 - 零宽字符需单独构造测试用例，例如
"a\u200bb"（中间有零宽空格），验证 pattern 是否忽略或捕获它
避免在测试中依赖外部 regex 引擎行为差异
Python 的 re 模块不支持某些高级特性（如原子组、固化分组），而 regex 第三方库支持。如果项目用了 regex，测试必须用它，否则本地通过、CI 失败。
另一个隐形陷阱：不同 Python 版本对 Unicode 类别支持略有差异（比如 \p{L} 在 re 中根本无效，在 regex 中才可用），测试环境要和运行环境一致。
- 检查
requirements.txt里是否明确指定了regex；若用了，测试中 import 必须是import regex as re，而非import re - 用
sys.version_info控制版本相关用例，比如 Python re.escape(..., escape_bytes=False) - 不要假设
re.sub的替换字符串语法跨引擎一致——\g和\1在某些上下文行为不同
边界测试最难的不是写多少 case，而是识别哪些“看似正常”的输入其实触发了正则引擎的隐式行为，比如回溯爆炸、贪婪匹配截断、Unicode 归一化干扰。每次加新 case 前，先问一句：这个输入在真实用户数据里可能出现吗？它会不会让 pattern 耗尽栈或超时？
