密码强度校验这个需求，几乎每个带注册流程的项目都会碰到。我最早的做法特别粗暴——正则卡长度、卡大小写、卡特殊字符，凑齐四条就亮绿灯。上线之后用户投诉不断，说密码明明很复杂却被判弱，也有人随手敲个Abc123!就过了，安全团队回头一扫，弱口令一大片。后来我把方案换成了zxcvbn做强度估算，前端展示层用Ant Design的组件体系来搭，做出来的效果既好看又真正能反映密码的真实强度。这篇就把这套密码强度组件的完整实现拆开讲清楚，从选型逻辑、核心原理、代码落地到踩坑经验，全部摊开说，你拿到就能直接往项目里搬。
1. 为什么放弃正则，转向 zxcvbn 做强度估算
1.1 正则校验的根本缺陷：只认规则，不认“像不像密码”
先说清楚正则方案为什么不够用。传统正则校验的本质是规则匹配：长度够不够、有没有大写、有没有数字、有没有符号。这套逻辑的问题在于，它衡量的是“密码是否符合格式要求”，而不是“密码有多难被猜出来”。
举个特别典型的例子。P@ssw0rd!这个密码，长度 9 位，有大写、有小写、有数字、有特殊符号，正则方案会给它满分。但任何一个做过安全审计的人都知道，这是全球弱口令榜单上的常客，攻击者字典里排前几百位。反过来，correcthorsebatterystaple这种全小写、无数字、无符号的密码，正则方案会判它“弱”，但实际上它的熵值极高，暴力破解的成本远超前者。
这就是正则方案的核心矛盾：它把“复杂度”等同于“安全性”，但真正的安全性取决于可预测性。密码越像常见词汇、常见模式、常见键盘路径，就越容易被字典攻击和模式匹配攻击命中，哪怕它看起来很长很复杂。
我在实际项目里做过统计，正则方案误判率大概在 15% 到 25% 之间——要么把强密码判弱（用户体验差），要么把弱密码判强（安全风险）。这个数字在金融、医疗这类对安全敏感的行业里是不可接受的。
1.2 zxcvbn 的估算逻辑：用“猜测次数”量化强度
zxcvbn 的思路完全不一样。它不看你符不符合规则，而是估算攻击者需要多少次猜测才能破解这个密码，这个数值叫guesses，然后取对数换算成熵值（entropy），再映射到 0 到 4 的评分区间。
它的估算过程大致分几步。第一步是模式识别，把密码拆解成若干片段，识别每个片段属于哪种模式：字典词、常见姓名、键盘空间模式（比如qwerty、asdf）、日期、重复字符、序列（比如123456、abcdef）、l33t 替换（比如p@ssw0rd里的@替换a）。第二步是匹配代价计算，每种模式都有一个“猜测成本”，比如字典词的成本取决于它在词库里的排名，排名越靠前成本越低。第三步是组合最优解，用动态规划找出把密码拆成片段的所有方式中，总猜测成本最低的那一种——因为攻击者永远会用最省力的方式破解。
最后得到的guesses值，经过对数变换后映射到评分：
| 评分 | 熵值范围（约） | 猜测次数量级 | 含义 | 建议处理 |
|---|---|---|---|---|
| 0 | < 28 bits | < 10^3 | 极易破解 | 直接拒绝 |
| 1 | 28 - 35 bits | 10^3 - 10^6 | 很弱 | 强烈提示 |
| 2 | 36 - 59 bits | 10^6 - 10^10 | 一般 | 允许但提示 |
| 3 | 60 - 127 bits | 10^10 - 10^14 | 强 | 正常放行 |
| 4 | >= 128 bits | > 10^14 | 很强 | 正常放行 |
这个映射不是拍脑袋定的，背后是离线快速哈希（比如每秒百亿次量级）和在线限速场景下的破解时间估算。评分 2 对应的 10^10 次猜测，在离线攻击场景下可能几小时就破了，所以我在项目里通常把最低通过线设在评分 3，评分 2 允许提交但给黄色警告，评分 0 和 1 直接拦截。
注意：zxcvbn 的评分是“相对强度”，不是绝对安全保证。它防的是字典攻击和模式攻击，防不了针对性的社工攻击（比如用生日、宠物名做密码）。所以组件里除了强度条，还得配提示文案引导用户避开个人信息。
1.3 选 zxcvbn 而不是自研的取舍
市面上做密码强度的方案不止 zxcvbn 一家，有自研规则引擎的，有用简化版熵值计算的，也有用其他开源库的。我选 zxcvbn 主要看中三点。
第一是词库覆盖足够全。zxcvbn 内置了常见密码、英文单词、人名姓氏、键盘模式等多套字典，还支持按语言扩展。自研方案要维护这么全的词库，成本极高，而且更新滞后。
第二是反馈信息有指导性。zxcvbn 返回的feedback对象里，warning字段会告诉你“这是常见密码”“这是键盘模式”，suggestions字段会给具体建议，比如“加几个不相关的词”“避免用重复字符”。这些文案直接能用在 UI 上，省了大量产品文案工作。
第三是体积可控。zxcvbn 完整包压缩后大概 400KB 左右，对首屏影响不小。但它支持按需加载——密码输入框聚焦时才动态 import，用户不碰密码框就不加载。这个策略我在多个项目里验证过，对首屏性能几乎无感。
代价也有：zxcvbn 的计算在主线程跑，复杂密码估算可能耗时几十毫秒。所以我在实现里加了防抖，输入停止 300ms 后才触发估算，避免每次按键都算一遍卡顿。
2. 组件整体设计与 Ant Design 的配合思路
2.1 组件职责边界：只做“估算 + 展示”，不做“拦截”
设计组件时我给自己划了条线：这个组件只负责把密码强度算出来、展示出来，不负责决定能不能提交。拦截逻辑放在表单校验层，组件通过回调把评分和反馈抛出去，由外层决定怎么处理。
这么设计的原因很实际。同一个强度组件，注册场景要求评分 >= 3，改密码场景可能只要求 >= 2（老用户密码可能本来就弱，强制太严会卡住流程），后台管理场景可能要求 >= 4。如果把拦截逻辑写死在组件里，每个场景都得改组件，复用性就没了。职责分离之后，组件是纯展示 + 计算，业务规则在外层配置，干净得多。
组件的输入输出我定义成这样：
interface PasswordStrengthProps { value: string; // 受控的密码值 onChange?: (value: string) => void; // 值变化回调 onScoreChange?: (score: number, feedback: ZxcvbnResult['feedback']) => void; minScore?: number; // 最低通过评分，默认 3 showFeedback?: boolean; // 是否展示反馈文案，默认 true }onScoreChange是关键，外层拿到评分后自己做校验决策。minScore只影响组件内部的视觉状态（比如低于阈值时进度条变红），不直接阻断。
2.2 视觉层用 Ant Design 的哪些组件
Ant Design 的组件体系里，适合做这个场景的有几个：Input.Password做密码输入（自带显隐切换），Progress做强度条，Space或Flex做布局，Typography.Text做提示文案，Alert或自定义的提示条做警告。
强度条我用Progress而不是自己画 div，原因是Progress自带strokeColor、percent、showInfo这些属性，改颜色和百分比一行搞定，而且它的动画过渡是内置的，评分变化时进度条平滑过渡，视觉上很舒服。颜色映射我按评分来：
const SCORE_COLORS = ['#ff4d4f', '#ff7a45', '#faad14', '#52c41a', '#237804']; const SCORE_LABELS = ['极弱', '很弱', '一般', '强', '很强'];这里有个细节：Ant Design 的Progress默认percent是 0 到 100，而 zxcvbn 评分是 0 到 4。我做了个映射，percent = (score + 1) * 20，这样评分 0 显示 20%（不是 0%，因为 0% 看起来像没加载），评分 4 显示 100%。这个映射让进度条始终有可见的填充，用户能直观感受到“有强度但不够”。
2.3 状态机设计：空、弱、中、强、达标五种状态
组件内部其实是个小状态机，我梳理了五种状态，每种对应不同的视觉表现和文案策略：
- 空状态：密码为空，不显示强度条，只显示输入框。
- 弱状态（评分 0-1）：进度条红色，显示警告文案，输入框边框变红。
- 中状态（评分 2）：进度条黄色，显示建议文案，输入框边框正常。
- 强状态（评分 3）：进度条绿色，显示“强度良好”，输入框边框正常。
- 达标状态（评分 4）：进度条深绿，显示“强度很强”，可以加个对勾图标。
状态切换的触发点是value变化和score变化。我用useMemo缓存 zxcvbn 的计算结果，依赖value，避免重复计算。这里有个坑：zxcvbn 的zxcvbn()函数每次调用都会重新跑一遍估算，如果直接在 render 里调用，每次父组件重渲染都会算一遍，性能很差。用useMemo包一层是必须的。
3. 核心实现：从零写出可复用的强度组件
3.1 环境准备与依赖安装
先把依赖装好。zxcvbn 的 npm 包名是zxcvbn，类型定义在@types/zxcvbn。Ant Design 按你项目版本装，我用的是 v5。
npm install zxcvbn npm install -D @types/zxcvbn如果你用的是 TypeScript，装完类型包后import zxcvbn from 'zxcvbn'就能直接用，返回值类型是ZxcvbnResult，包含score、guesses、feedback、crackTimesDisplay等字段。
提示：zxcvbn 包体积不小，建议用动态 import 按需加载。下面 3.2 节会给具体写法。
3.2 动态加载 zxcvbn，避免拖慢首屏
zxcvbn 完整包压缩后 400KB 左右，直接静态 import 会进主 chunk，首屏加载时间明显变长。我的做法是密码框聚焦时才加载，用useState存加载状态，useEffect里触发动态 import。
import { useState, useEffect, useMemo } from 'react'; type ZxcvbnFn = typeof import('zxcvbn').default; let zxcvbnCache: ZxcvbnFn | null = null; function useZxcvbn() { const [zxcvbn, setZxcvbn] = useState<ZxcvbnFn | null>(zxcvbnCache); useEffect(() => { if (zxcvbnCache) return; let cancelled = false; import('zxcvbn').then((mod) => { if (cancelled) return; zxcvbnCache = mod.default; setZxcvbn(() => mod.default); }); return () => { cancelled = true; }; }, []); return zxcvbn; }这里用了个模块级变量zxcvbnCache做缓存，多个组件实例共享同一份加载结果，不会重复 import。setZxcvbn(() => mod.default)用函数式更新，是因为 zxcvbn 本身是个函数，直接setZxcvbn(mod.default)会被 React 当成“用函数更新 state”处理，导致把mod.default当 updater 执行，这是个很隐蔽的坑，我第一次写就踩了。
3.3 强度计算与防抖处理
拿到 zxcvbn 函数后，计算逻辑本身很简单，但必须加防抖。用户连续输入时，每次按键都算一遍，复杂密码单次估算可能 30-50ms，连续输入会明显卡顿。
import { useDebouncedValue } from './useDebouncedValue'; // 自定义防抖 hook function usePasswordStrength(password: string, zxcvbn: ZxcvbnFn | null) { const debouncedPassword = useDebouncedValue(password, 300); return useMemo(() => { if (!zxcvbn || !debouncedPassword) return null; return zxcvbn(debouncedPassword); }, [zxcvbn, debouncedPassword]); }防抖延迟我设 300ms，这个值有讲究。设太短（比如 100ms）防抖效果不明显，快速输入时还是会频繁计算；设太长（比如 500ms）用户输完密码后要等半秒才看到强度条，体验拖沓。300ms 是实测下来比较平衡的值，用户输完最后一个字符，大概停顿一下就能看到结果。
useDebouncedValue的实现很常规，用setTimeout+clearTimeout：
import { useState, useEffect } from 'react'; export function useDebouncedValue<T>(value: T, delay: number): T { const [debounced, setDebounced] = useState(value); useEffect(() => { const timer = setTimeout(() => setDebounced(value), delay); return () => clearTimeout(timer); }, [value, delay]); return debounced; }3.4 完整组件代码与视觉细节
把上面几块拼起来，就是完整的组件。我贴一份可以直接用的版本，注释里标了关键点。
import React, { useMemo } from 'react'; import { Input, Progress, Typography, Space } from 'antd'; import type { ZxcvbnResult } from 'zxcvbn'; import { useZxcvbn } from './useZxcvbn'; import { useDebouncedValue } from './useDebouncedValue'; const { Text } = Typography; const SCORE_COLORS = ['#ff4d4f', '#ff7a45', '#faad14', '#52c41a', '#237804']; const SCORE_LABELS = ['极弱', '很弱', '一般', '强', '很强']; interface PasswordStrengthProps { value: string; onChange?: (value: string) => void; onScoreChange?: (score: number, feedback: ZxcvbnResult['feedback']) => void; minScore?: number; showFeedback?: boolean; } export const PasswordStrength: React.FC<PasswordStrengthProps> = ({ value, onChange, onScoreChange, minScore = 3, showFeedback = true, }) => { const zxcvbn = useZxcvbn(); const debouncedValue = useDebouncedValue(value, 300); const result = useMemo(() => { if (!zxcvbn || !debouncedValue) return null; return zxcvbn(debouncedValue); }, [zxcvbn, debouncedValue]); // 评分变化时通知外层 React.useEffect(() => { if (result && onScoreChange) { onScoreChange(result.score, result.feedback); } }, [result, onScoreChange]); const score = result?.score ?? 0; const percent = value ? (score + 1) * 20 : 0; const color = SCORE_COLORS[score]; const label = SCORE_LABELS[score]; const isBelowMin = value && score < minScore; return ( <Space direction="vertical" style={{ width: '100%' }} size={8}> <Input.Password value={value} onChange={(e) => onChange?.(e.target.value)} placeholder="请输入密码" status={isBelowMin ? 'error' : undefined} autoComplete="new-password" /> {value && ( <> <Progress percent={percent} strokeColor={color} showInfo={false} size="small" style={{ margin: 0 }} /> <div style={{ display: 'flex', justifyContent: 'space-between' }}> <Text style={{ color, fontSize: 12 }}>强度：{label}</Text> {result?.crackTimesDisplay?.offlineFastHashing1e10PerSecond && ( <Text type="secondary" style={{ fontSize: 12 }}> 破解耗时：{result.crackTimesDisplay.offlineFastHashing1e10PerSecond} </Text> )} </div> {showFeedback && result?.feedback?.warning && ( <Text type="warning" style={{ fontSize: 12 }}> {result.feedback.warning} </Text> )} {showFeedback && result?.feedback?.suggestions?.length > 0 && ( <Text type="secondary" style={{ fontSize: 12 }}> {result.feedback.suggestions.join('；')} </Text> )} </> )} </Space> ); };几个视觉细节值得单独说。Input.Password的status="error"会让输入框边框变红，这个和强度条颜色是联动的，低于minScore时触发。Progress的size="small"让进度条细一点，不抢输入框的视觉焦点。crackTimesDisplay里我选了offlineFastHashing1e10PerSecond这个场景，它对应“离线快速哈希攻击”，是最严苛的破解场景，展示这个数值对用户最有警示意义。
注意：
crackTimesDisplay的字段名在不同版本 zxcvbn 里可能有差异，用之前先console.log确认一下当前版本返回的字段结构，别直接照抄。
3.5 表单集成：把组件挂进 Form.Item
组件单独用没问题，但实际项目里都是挂在 Ant Design 的Form里。集成时有两个点要注意：一是Form.Item的rules里要加自定义校验，二是onScoreChange要把评分存到表单外部状态，供提交时判断。
const [passwordScore, setPasswordScore] = useState(0); <Form.Item name="password" label="密码" rules={[ { required: true, message: '请输入密码' }, { validator: (_, value) => { if (!value) return Promise.resolve(); if (passwordScore < 3) { return Promise.reject(new Error('密码强度不足，请参考下方建议加强')); } return Promise.resolve(); }, }, ]} > <PasswordStrength onScoreChange={(score) => setPasswordScore(score)} /> </Form.Item>这里有个时序问题：onScoreChange是防抖后触发的，用户输完密码立刻点提交，可能评分还没更新，校验用的是旧值。我的处理是在validator里不依赖passwordScore，而是同步再算一次——虽然多算一次，但保证校验准确。或者更简单，把防抖延迟调短到 150ms，并在提交按钮上加个 loading 态，等防抖窗口过去再允许提交。两种方案我都用过，前者更稳，后者体验更顺，看项目取舍。
4. 实操中踩过的坑与排查实录
4.1 常见问题速查表
这套组件我在三个项目里落地过，踩的坑不算少，整理成表方便你对照排查。
| 问题现象 | 可能原因 | 排查方法 | 解决方案 |
|---|---|---|---|
| 强度条一直不显示 | zxcvbn 未加载完成 | 检查useZxcvbn返回是否为 null | 确认动态 import 路径正确，检查网络面板是否加载成功 |
| 输入后卡顿明显 | 未加防抖或防抖失效 | 在zxcvbn()调用处打时间戳 | 确认useDebouncedValue生效，延迟设 300ms |
| 评分与预期不符 | 密码含个人信息未识别 | 打印result.feedback看 warning | zxcvbn 不识别业务特定词，需在词库层扩展或前端额外校验 |
| 进度条颜色不更新 | strokeColor传了函数或对象 | 检查SCORE_COLORS[score]是否为字符串 | 确保传的是颜色字符串，不是渐变对象 |
| 表单校验时序错乱 | 防抖导致评分滞后 | 在 validator 里打印当前 score | 改为 validator 内同步计算，或提交前等待防抖 |
| 移动端输入框抖动 | 强度条出现导致布局位移 | 检查强度条容器高度是否固定 | 给强度条区域设固定minHeight，避免撑开布局 |
4.2 三个最坑的细节
第一个坑：zxcvbn 的feedback可能是空对象。密码强度很高时，feedback.warning是空字符串，feedback.suggestions是空数组。如果直接result.feedback.warning.length > 0判断，空字符串没问题，但如果写成result.feedback.warning && ...，空字符串是 falsy，逻辑也对。真正坑的是有些版本feedback本身可能是undefined，所以访问前要result?.feedback?.warning，可选链不能省。
第二个坑：Input.Password的status属性和Form.Item的校验状态会打架。Form.Item校验失败时会给子组件注入status="error"，如果组件内部又根据isBelowMin设了status，两者会冲突，表现为边框颜色闪烁。我的解法是组件内部不设status，完全交给Form.Item管，组件只负责强度条和文案。这样职责更清晰，也避免了样式冲突。
第三个坑：动态 import 在 SSR 环境会报错。如果项目用了 Next.js 这类 SSR 框架，import('zxcvbn')在服务端执行会因为没有window对象而报错。解法是用next/dynamic的ssr: false包一层，或者在useEffect里判断typeof window !== 'undefined'再加载。我现在的写法是在useZxcvbn的useEffect里加了这个判断，SSR 时直接跳过，客户端 hydration 后再加载。
4.3 性能实测数据
我在一个中等规模项目里测过这套组件的性能影响。测试环境是普通办公笔记本，Chrome 最新版。
| 指标 | 静态 import | 动态 import + 防抖 |
|---|---|---|
| 首屏 JS 体积增量 | +420KB（gzip 后约 130KB） | 0（密码框聚焦后才加载） |
| 首屏加载时间影响 | +180ms | 0 |
| 单次强度计算耗时（8 位复杂密码） | 约 35ms | 约 35ms（防抖后只算一次） |
| 连续输入 20 字符总计算耗时 | 约 700ms（每次按键都算） | 约 35ms（防抖后只算最后一次） |
数据很直观：动态 import 把首屏影响降到零，防抖把连续输入的计算耗时从 700ms 压到 35ms。这两个优化不做，组件能用但体验很差，做了之后基本无感。
5. 强度阈值策略与业务场景适配
5.1 不同场景的阈值怎么定
前面提过，minScore不该写死。我按场景给了一套参考值，你可以直接抄：
| 业务场景 | 建议 minScore | 理由 |
|---|---|---|
| 普通用户注册 | 3 | 平衡安全与转化，评分 2 允许但提示 |
| 金融/支付类注册 | 4 | 安全优先，宁可牺牲部分转化 |
| 老用户改密码 | 2 | 避免老密码本身弱导致无法修改 |
| 后台管理登录 | 4 | 高权限账号，强度要求最高 |
| 临时访客账号 | 1 | 生命周期短，强度要求可放宽 |
这套阈值不是绝对的，得结合你的用户画像调。我做过一个面向中老年用户的健康类产品，注册转化率对评分阈值极其敏感——阈值从 3 降到 2，转化率涨了 8 个百分点。所以上线前一定要做 A/B 测试，别拍脑袋定。
5.2 反馈文案的本地化处理
zxcvbn 的feedback是英文的，直接展示给中文用户很别扭。我的做法是建一个映射表，把常见的 warning 和 suggestions 翻译过来，没匹配到的走兜底文案。
const WARNING_MAP: Record<string, string> = { 'This is a top-10 common password': '这是最常见的密码之一，请更换', 'This is a top-100 common password': '这是常见密码，容易被猜到', 'This is a very common password': '这是非常常见的密码', 'This is similar to a commonly used password': '与常见密码过于相似', 'A word by itself is easy to guess': '单个单词很容易被猜到', 'Names and surnames by themselves are easy to guess': '姓名本身很容易被猜到', 'Common names and surnames are easy to guess': '常见姓名很容易被猜到', 'Straight rows of keys are easy to guess': '键盘上连续的按键很容易被猜到', 'Short keyboard patterns are easy to guess': '短键盘模式很容易被猜到', 'Repeats like "aaa" are easy to guess': '重复字符很容易被猜到', 'Repeats like "abcabcabc" are only slightly harder to guess than "abc"': '重复模式强度提升有限', 'Sequences like abc or 6543 are easy to guess': '连续序列很容易被猜到', 'Recent years are easy to guess': '近年份数字很容易被猜到', 'Dates are often easy to guess': '日期很容易被猜到', };映射表覆盖了 zxcvbn 内置的大部分 warning，剩下的走“密码强度不足，建议增加长度和随机性”这类兜底。suggestions 同理，翻译成“增加密码长度”“混合使用大小写和符号”“避免使用个人信息”这类可操作的建议。
提示：映射表要跟着 zxcvbn 版本更新。升级 zxcvbn 后，先跑一遍测试用例，把新增的 warning 补进映射表，否则会出现英文文案漏出。
5.3 与后端校验的配合
前端强度校验只是第一道关，后端必须再校验一次。原因很简单：前端代码可以被绕过，攻击者直接调接口传弱密码，前端拦不住。后端的校验策略我建议这样：后端用同样的 zxcvbn 逻辑再算一遍评分，低于阈值直接拒绝，同时记录拒绝日志，用于分析用户密码习惯。
后端用 Node.js 的话，直接npm install zxcvbn就能复用同一套逻辑，保证前后端评分一致。用其他语言的话，zxcvbn 有 Python、Java、Go 等多语言移植版，逻辑基本对齐，但词库版本可能有差异，需要做一致性测试。
前后端评分不一致是个隐蔽的坑。我遇到过前端显示评分 3 通过，后端算出评分 2 拒绝的情况，用户一脸懵。排查发现是前后端 zxcvbn 版本不同，词库有差异。解法是锁定前后端 zxcvbn 版本号，升级时同步升，并在 CI 里加一致性测试用例。
6. 组件扩展：还能怎么玩
6.1 加一个“密码生成器”入口
强度组件旁边挂个“生成强密码”按钮，点击后用crypto.getRandomValues生成一个高熵密码，直接填进输入框。这个功能对用户很友好，尤其是那些不想动脑想密码的人。生成逻辑我一般用字符集随机组合，长度 16 位，保证评分稳定在 4。
function generateStrongPassword(length = 16): string { const charset = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789!@#$%^&*'; const values = new Uint32Array(length); crypto.getRandomValues(values); return Array.from(values, (v) => charset[v % charset.length]).join(''); }用crypto.getRandomValues而不是Math.random，是因为后者不是密码学安全的随机源，生成的密码可预测性更高。这个细节很多人忽略，但既然做安全相关的东西，就得较真。
6.2 强度历史记录与趋势提示
进阶玩法是记录用户输入过程中的评分变化，画一条小趋势线，提示“你的密码强度在提升”。这个功能对引导用户改强密码很有效，实测能让用户多尝试 2 到 3 次。实现上用useRef存评分历史数组，每次评分变化 push 进去，用简单的 SVG 折线画出来。不过这个属于锦上添花，核心功能稳定后再加，别一上来就堆功能。
6.3 无障碍访问的补强
强度条是纯视觉的，屏幕阅读器读不到。我加了aria-live="polite"的隐藏文本，评分变化时播报“密码强度：强”。Progress组件加aria-label，输入框加aria-describedby指向提示文案。这些细节不影响普通用户，但对无障碍访问是必须的，尤其是面向公众的产品，合规检查会看这个。
7. 我个人的几条实操心得
这套组件从第一版到现在，改了不下十次，有几个心得是文档里不会写的。
别迷信评分，要看场景。zxcvbn 评分 4 的密码，如果包含用户生日，社工攻击照样能破。所以我在组件外层还加了一层“个人信息检测”，把用户名、邮箱前缀、手机号后几位做子串匹配，命中就降一级评分。这层逻辑 zxcvbn 不管，得自己补。
防抖延迟和提交按钮要联动。用户输完密码立刻点提交，防抖还没触发，评分是旧的。我的做法是提交按钮在密码框有内容且防抖未完成时显示 loading，等防抖完成再允许点击。这个交互细节能避免大量“明明密码很强却提示弱”的客诉。
词库扩展比调阈值更有效。如果业务有特定词汇（比如产品名、行业术语），把这些词加进 zxcvbn 的自定义字典，比单纯调高minScore更精准。zxcvbn 支持传userInputs参数，把业务词传进去，它会把这些词当弱模式处理。
测试用例要覆盖边界。我维护了一组测试密码，从123456到随机 20 位字符串，每次改组件都跑一遍，确保评分映射、颜色、文案都没跑偏。这组用例还兼做前后端一致性测试，一举两得。
最后说个我踩过最深的坑：早期版本我把 zxcvbn 静态 import 进组件，结果整个注册页首屏体积暴涨，Lighthouse 性能分掉了 15 分。改成动态 import 后分数回来了，但忘了处理 SSR 报错，上线后服务端渲染直接 500。这两个坑连着踩，让我彻底记住了“安全组件也要考虑性能和无 SSR 兼容”。现在我的习惯是，任何引入第三方大包的组件，先问三个问题：能不能按需加载、会不会影响首屏、SSR 环境跑不跑得通。这三个问题问完，大部分坑就提前避掉了。
