regexp.matchString易漏判弱密码因默认子串匹配，须用^和$锚点确保全匹配；应拆分规则、预编译正则；优先用strings/unicode遍历统计；慎用zxcvbn-go；须归一化unicode并过滤控制字符。
为什么 regexp.MatchString 在密码检测里容易漏判弱密码
因为正则默认不强制全匹配，只找子串。比如用 ^[a-z]+$ 检查“abc123”，它会返回 false（正确），但若误写成 [a-z]+（缺 ^ 和 $），就会对 “abc123” 返回 true——只匹配了前面三个小写字母，完全没管后面的数字和长度。
- 密码检测必须用锚点：
^开头、$结尾，否则只是“是否含某类字符”，不是“是否仅由某类字符组成” - 别依赖单个正则覆盖所有规则；拆成多个独立检查更清晰、易调试
-
regexp.MatchString性能尚可，但若每秒校验上千次密码（如 API 频繁调用），建议预编译正则：用regexp.MustCompile存为包级变量，避免重复编译开销
如何用 strings + unicode 做无正则的字符分类统计
正则适合“模式存在性判断”，但“至少含 2 个大写字母”“数字不能连续超过 3 位”这类计数/位置逻辑，硬塞进正则会让表达式爆炸且难维护。golang 的 strings 和 unicode 包遍历一次就能拿到全部信息。
- 用
unicode.IsUpper、unicode.IsDigit等逐 rune 判断，比regexp更准（支持 Unicode 字符，比如中文密码场景） - 边遍历边记录：当前连续数字个数、上次字符类型、大小写首次出现位置——这些状态正则根本没法存
- 示例片段：
for _, r := range password { if unicode.IsDigit(r) { digitCount++ if lastWasDigit { consecutiveDigits++ } else { consecutiveDigits = 1 } lastWasDigit = true } else { lastWasDigit = false } }
zxcvbn-go 库在真实项目中为什么常被弃用
它能识别常见弱口令（如 password123、qwerty）、键盘序列、年份模式，理论很美，但落地时问题集中：
- 体积大：引入后二进制增大 2–3MB，对 CLI 工具或嵌入式场景敏感
- 内存占用高：加载词典时会初始化大量 map 和 slice，冷启动慢，在 serverless 环境可能触发超时
- 定制难：无法关闭“常见单词检测”而只保留“模式分析”，也不支持注入企业专属弱密码黑名单
- 更务实的做法：用它做 baseline 测试集，自己实现轻量核心逻辑（长度+字符集+重复/顺序检测），关键路径避开它
测试时最容易忽略的边界：空字符串、Unicode 组合字符、零宽空格
用户粘贴密码时可能混入不可见字符，比如 u200b（零宽空格）或 emoji 中的组合标记（如 ??），它们会让 len(password) 和 utf8.RuneCountInString(password) 不一致，导致长度判断出错。
立即学习“go语言免费学习笔记（深入）”；
- 务必在检测前 normalize：用
golang.org/x/text/unicode/norm的NFC.String处理，合并组合字符 - 过滤控制字符：遍历 rune 时跳过
unicode.IsControl和unicode.IsSpace（除非你明确允许空格作为密码字符） - 单元测试必须包含：
"au200bb"、"u00e9"（é）、"??"——别只测 ASCII
事情说清了就结束