HTML5的type="password"仅实现字符遮掩，不加密、不防抓包、不验证；真正安全依赖HTTPS传输、服务端强哈希存储及前后端协同校验。
HTML5 本身不提供“密码安全机制”，type="password" 只是前端遮掩输入，不加密、不验证、不防抓包——所有靠 <input type="password"> 单独实现的“保护”都是假象。
为什么 type="password" 根本不安全
它只做一件事：把输入字符显示为 ●●●，其他什么都没做。真实值仍以明文存在 DOM 中，可被 JS 任意读取；表单提交时若没走 HTTPS，密码会裸奔到服务器；服务端若没校验或哈希存储，数据库一泄露就全完。
- 浏览器开发者工具里直接
document.querySelector('input[type=password]').value就能拿到明文 - 禁用 JS 或绕过前端校验（如删掉
required、改maxlength）毫无门槛 -
autocomplete="off"在现代浏览器中基本失效，Chrome 甚至会忽略它并自动填充
真正起作用的安全动作在后端和传输层
前端唯一能做的，是配合后端建立合理流程。重点不是“怎么写 HTML”，而是“怎么不让密码裸露在链路中”：
- 必须启用 HTTPS：否则任何前端防护都形同虚设，中间人可截获 POST body 中的明文密码
- 服务端接收后立即用强哈希（如
bcrypt、Argon2）加盐处理，绝不可存明文或简单 MD5/SHA1 - 登录接口需防暴力：限制尝试次数、加验证码、记录异常 IP
- 敏感操作（如改密、转账）应二次验证，不能仅依赖登录态
前端能做的有限但关键的配合项
不是“设密码”，而是“减少密码暴露面”：
立即学习“前端免费学习笔记（深入）”；
- 用
autocomplete="new-password"（注意不是off）提示浏览器不要填充旧密码，对新注册/改密页更有效 - 避免在 URL 中传密码（如
GET /login?pwd=xxx），永远用POST+application/x-www-form-urlencoded或 JSON - 密码框失去焦点时清空临时变量：
input.addEventListener('blur', () => input.value = '')，防止内存残留（仅辅助，不替代 HTTPS 和哈希） - 若用 Web Crypto API 做客户端加盐（极少见且需谨慎），必须确认密钥不硬编码、不依赖用户可控输入
最常被忽略的一点：密码强度策略（如大小写+数字+长度）必须前后端双重校验。前端用 pattern 或 JS 检查只是体验优化，后端没校验等于没设防。
