密码强度条应使用Bootstrap的progress组件，用包裹，通过style="width:X%;"控制进度，配合bg-*类、role="progressbar"及aria-valuenow实现语义化与无障碍支持。
密码强度条用 progress 组件最直接
Bootstrap 自带的 progress 组件不是装饰品，它天生适合做强度可视化。别套壳写 div + background 模拟进度条，原生 progress 语义清晰、键盘可聚焦、屏幕阅读器友好，且支持 aria-valuenow 动态标注当前强度值。
关键点：必须用 <div class="progress"> 包裹 <code><div class="progress-bar">，不能只写一个 <code>progress-bar —— 否则高度塌陷、圆角失效、动画丢失。
- 强度值用
style="width: 40%;"控制，不要用value属性（那是 HTML5<progress></progress>原生标签的写法，和 Bootstrap 的 class-based 进度条不兼容） - 颜色按强度分级：弱用
bg-danger，中用bg-warning，强用bg-success，极强可用bg-primary - 加
role="progressbar"和aria-valuenow属性，方便辅助技术读取，比如：<div class="progress-bar bg-warning" role="progressbar" aria-valuenow="65" aria-valuemin="0" aria-valuemax="100" style="width: 65%;"></div>
input[type="password"] 要绑定实时检测逻辑
外观只是表层，真正驱动进度条的是输入事件。别用 change（只在失焦时触发），得用 input 事件监听每次按键，包括粘贴、剪切、自动填充——这些操作 input 都能捕获，keyup 会漏掉。
注意：Bootstrap 不提供密码强度算法，你得自己写或引入轻量库（如 zxcvbn）。但外观层只需接收一个 0–100 的分数，然后映射到进度条宽度和颜色类。
- 监听时加防抖（比如 150ms），避免高频触发影响性能，尤其在移动端
- 空密码时设
width: 0%并移除所有bg-*类，避免残留上一次的颜色 - 检测前先
.trim()，防止用户只输空格还显示“中等强度”
文字提示放 .form-text 里才对齐且响应式
“太短”“需数字”“很强”这类提示，别塞进 progress 里或用绝对定位盖上去。Bootstrap 的 .form-text 是专为表单辅助文本设计的，字号小、颜色浅、上下间距合理，而且在 .form-group 或 .mb-3 容器下能自然换行、适配小屏。
错误提示和成功提示共存时，别用同一个 DOM 节点反复 innerHTML —— 容易闪动或残留旧文案。建议提前写好两个 <p class="form-text text-muted"></p>，一个标 id="pw-hint" 显示规则，一个标 id="pw-score" 显示当前强度描述（如“强”），按分数切换显隐。
- 分数 ≤ 30：提示“至少 8 位，含大小写字母、数字、符号”
- 31–60：提示“已包含两类字符”
- 61–89：提示“很好，再加个符号更安全”
- ≥ 90：提示“非常强 ✅”，此时可加
text-success类强化正向反馈
移动端触摸体验容易被忽略
在 iOS Safari 或 Android Chrome 上，如果进度条区域太窄（比如只有 4px 高），用户根本点不到、拖不了——但这不是问题，因为密码强度条本就不该可交互。重点是：别给 .progress-bar 加 cursor: pointer 或 touch-action: manipulation，否则会误导用户以为能拖动；同时确保父容器 .progress 有足够点击热区（最小 44×44px），避免跟下方按钮重叠导致误触。
另一个坑：iOS 输入法自动大写首字母，可能让纯小写字母密码误判为“含大写”。检测前统一转成小写再分析字符集，但最终展示仍按原始输入（比如用户输 Abc123!，就别显示“您输入了 abc123!”）。
真正麻烦的是 autofill —— Chrome 有时会跳过 input 事件，得监听 animationstart 或用 MutationObserver 监控 value 变化作为兜底，不过多数场景加个 300ms 延迟检测就能覆盖。
