应拆分验证：用strlen()校长度，再用多个preg_match()分别检查大小写字母、数字和明确白名单的特殊字符，避免单正则前瞻断言导致ReDoS。
PHP 表单中用正则验证密码强度的常见写法
直接用 preg_match() 做基础强度校验最轻量，但容易写错逻辑或漏掉边界情况。核心是：必须同时满足多个条件（如大小写字母、数字、特殊字符、长度），不能只靠一个正则“一锤定音”。
典型错误是写成 /(?=.*[a-z])(?=.*[A-Z])(?=.*\d)(?=.*[!@#\$%\^&\*]).{8,}/ 然后以为万事大吉——这在 PCRE 默认模式下会因回溯失控导致拒绝服务（ReDoS），尤其当用户输入超长无效字符串时（比如 100 个 a）。
实操建议：
- 拆开验证：分别用多个
preg_match()检查小写、大写、数字、特殊字符，再用strlen()判长度，逻辑清晰且无回溯风险 - 特殊字符白名单要明确，避免用
[\W_]这类宽泛表达式，推荐[!@#\$%\^&\*\-\_=+\[\]\{\}\|;':",.\/?]（注意转义） - 若坚持单正则，必须加
u和D修饰符，并限制最大输入长度（如if (strlen($_POST['password']) > 64) die('密码过长');）
为什么 strlen() + 多次 preg_match 比单正则更可靠
PHP 的 preg_match() 在处理带大量前瞻断言（(?=...)）的正则时，引擎可能指数级回溯。真实表单场景中，攻击者可故意提交如 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa! 触发卡死。
立即学习“PHP免费学习笔记（深入）”；
而分步验证天然规避该问题：
$pwd = $_POST['password'];
$errors = [];
if (strlen($pwd) < 8) {
$errors[] = '密码至少 8 位';
}
if (!preg_match('/[a-z]/', $pwd)) {
$errors[] = '需含小写字母';
}
if (!preg_match('/[A-Z]/', $pwd)) {
$errors[] = '需含大写字母';
}
if (!preg_match('/\d/', $pwd)) {
$errors[] = '需含数字';
}
if (!preg_match('/[!@#\$%\^&\*]/', $pwd)) {
$errors[] = '需含至少一个特殊字符';
}
这种写法执行路径固定，性能稳定，调试也直观——哪个 if 不成立，就对应哪条规则未达标。
中文环境下的密码强度陷阱：Unicode 字符与空格
用户可能输入全角数字（如「１２３」）、中文标点（如「！＠＃」）或开头/结尾空格。这些不会被 /\d/ 或 /[!@#]/ 匹配到，导致误判“强度不足”。
应对方式：
- 提前用
trim()去首尾空格，避免用户无意中输错 - 如需支持 Unicode 数字，改用
preg_match('/\p{N}/u', $pwd)（需加u修饰符） - 但注意：大多数系统不鼓励用户用中文字符设密码，既难输入又难记忆，建议显式禁止非 ASCII 字符：
if (preg_match('/[^\x20-\x7E]/', $pwd)) { $errors[] = '请勿使用中文或全角字符'; }
前端 JS 校验和后端 PHP 校验必须都做
前端用 JavaScript 显示实时提示很友好，但完全不可信。用户禁用 JS、用 cURL 直接 POST、或绕过前端逻辑都是分分钟的事。
关键点：
- 前端校验仅用于体验优化，所有判断逻辑必须在 PHP 中完整复现一次
- 不要在 JS 里暴露正则细节（如把
/[a-z]/写死在前端），否则攻击者一眼看穿规则 - PHP 端校验后，记得对
$_POST['password']做htmlspecialchars()输出错误信息，防止 XSS
真正容易被忽略的是：很多人只在注册页校验强度，却忘了修改密码页（reset_password.php 或 profile_update.php）同样要套同一套验证逻辑——漏掉一个入口，整套强度策略就形同虚设。
