zxcvbn-php 不是官方包，Composer 安装的 dwyl/zxcvbn 已停止维护，PHP 原生集成效果差、性能低、结果不稳定，不可用于生产环境密码校验。

直接说结论：zxcvbn-php 不是官方包，Composer 安装的 dwyl/zxcvbn 早已停止维护，PHP 原生集成效果差、性能低、结果不稳定——别用它做生产环境的密码强度校验。

为什么 dwyl/zxcvbn 在 PHP 中基本不可靠

这个包本质是把 JavaScript 版 zxcvbn 通过 exec() 调用 Node.js 运行，或靠 eval() 解析 JSON 规则模拟行为。实际使用中常见问题包括：

• zxcvbn 的熵计算严重依赖字典和模式匹配，PHP 端无法完整复现 JS 的正则引擎和 Unicode 处理逻辑，导致评分偏差（比如对中文拼音、混合大小写数字的识别率极低）
• 每次校验都触发 node 子进程，QPS 上百就会卡住 Web 服务器，且无法复用上下文（如用户历史密码、邮箱、用户名等自定义字典）
• PHP 7.4+ 下 json_decode($json, true) 对嵌套过深的提示语数组解析失败，报错 Maximum stack depth exceeded

更可行的替代方案：前端 + 后端协同校验

真正落地的密码强度检测，从来不是只靠一个函数返回 score。关键在分层控制：

Academic Composer Upload

辅助学术写作，包括查找资料、生成大纲、引用扩写及润色风格，同时确保引用规范。

下载

• 前端用原生 zxcvbn（npm install zxcvbn）实时反馈，但仅作提示，不信任结果
• 后端必须强制执行基础规则：长度 ≥ 8、含大小写字母 + 数字 + 符号中的至少三类、不能包含用户名/邮箱/网站名子串
• 禁用常见弱口令：从 10k-most-common.txt 或 rockyou.txt（需脱敏处理）加载进 Redis，用 SSCAN 快速比对哈希前缀（如 sha256($pwd)[0:8]）
• 避免调用任何外部服务或子进程——所有判断必须在单次请求内完成，响应时间

如果非要 PHP 端跑 zxcvbn，只能选 spatie/zxcvbn

这是目前唯一持续更新、适配 PHP 8+ 的轻量封装，但它仍不解析原始 JS 字典，而是用预编译规则集。使用时注意：

• 安装命令是 composer require spatie/zxcvbn，不是 dwyl 那个
• 构造器必须传入自定义字典数组，否则对中文、拼音、本地化词汇完全无感：new Zxcvbn(['admin', 'companyname', '2024'])
• 返回的 guesses_log10 值要自己换算成强度等级：if ($result->getGuessesLog10() ，不要直接用 score 字段（它只是 0–4 的整数，粒度太粗）
• 每次实例化都重建规则树，高频场景下建议复用单例，但注意它不是线程安全的

真正难的不是“怎么调用 zxcvbn”，而是怎么定义“强”——业务要求用户改密码时不能和过去 5 次雷同，这需要查库比对哈希，而 zxcvbn 根本不解决这事。工具只是链路一环，别让它替你做权限、审计、策略的事。