type="password"仅改变UI显示，不提供实质安全；安全输入需HTTPS传输、后端强哈希、登录态绑定等全链路防护，前端加密若密钥暴露反而有害。
type="password" 不会拖慢安全输入，它本身没有计算开销，也不参与加密或校验——浏览器只是把字符画成圆点，仅此而已。
为什么“密码框”和“安全输入”根本不是一回事
很多人误以为加了 type="password" 就等于“做了安全输入”，其实两者完全不在一个层面：
-
type="password"是纯 UI 行为：只改显示、不改数据、不加密、不防抓包 - “安全输入”指整条链路的防护：HTTPS 传输 + 后端强哈希存储 + 登录态绑定 + 敏感操作二次确认
- 前端 JS 加密（如用 CryptoJS 做 SHA256）看似“更安全”，但密钥若硬编码或可被逆向，反而制造虚假安全感
autocomplete="new-password" 比 autocomplete="off" 更有效
现代浏览器（Chrome 93+、Safari 15+）基本忽略 autocomplete="off"，甚至会强制填充。真正起作用的是：
-
autocomplete="new-password"：明确告诉浏览器“这是新设密码”，避免复用旧密码建议 - 搭配随机
name属性（如name="pwd_8xk2mz"）可进一步降低识别率 - 多个密码字段（如“新密码”+“确认密码”）都必须设
autocomplete="new-password"，否则第二个可能被填入第一个的值
移动端 inputmode="text" 是刚需
iOS 和部分 Android 浏览器对 type="password" 默认弹出数字/符号键盘，用户输字母很别扭。解决方法很简单：
立即学习“前端免费学习笔记（深入）”；
- 显式加
inputmode="text"，确保调出全键盘 - 不要依赖
pattern或 JS 检查来“纠正”输入——用户可能直接绕过表单发请求 - 如果用了“显示密码”按钮，切换
type时注意：不要在 DOM 中长期保留明文value，blur 后可清空或转存到dataset
最常被忽略的一点：所有前端限制（minlength、pattern、required）都只服务体验，后端没做等价校验，就等于没设防。而 HTTPS 不是“可选项”，是底线——没它，type="password" 连遮羞布都算不上。
