不等于安全输入，它仅实现前端圆点遮蔽，明文仍存于dom、内存和网络传输中，必须配合https、后端哈希、webauthn等综合防护。
HTML 密码框（<input type="password">）本身不提供任何实质性的安全输入保护，它只是前端视觉遮蔽，对中间人、键盘记录、DOM 窥探、内存抓取等完全无防。真要防泄露，必须配合后端加密、HTTPS、敏感操作二次确认等机制，不能只靠 type="password"。
为什么 <input type="password"> 不等于安全输入
浏览器把输入内容变成圆点，仅是 UI 层面的掩码，原始值仍以明文存在 DOM 的 value 属性中，JS 可随时读取：document.getElementById('pwd').value 返回的就是明文。开发者调试时 console.log 一下就暴露；恶意脚本注入后也能立刻窃取；页面被快照或 DevTools 内存 dump 同样可还原。
常见错误现象包括：
- 在未启用 HTTPS 的页面用
<input type="password">提交，密码以明文发往服务器 - 用
localStorage缓存value，导致密码残留本地 - 将密码拼进 URL（如
location.href = '?pwd=' + pwd），留下历史记录和日志痕迹
替代方案：什么时候该放弃原生密码框
当需要规避 DOM 明文驻留、防止自动填充干扰、或集成硬件级认证时，原生 <input type="password"> 就成了风险点。此时可考虑以下替代路径：
- 用
<input type="text">+ 自定义遮蔽（如每字符渲染 ●），同时禁用autocomplete="off"和spellcheck="false"，并监听input事件实时截获键码（非value）做前端加盐哈希（仅限特定场景，如本地密钥派生） - 调用 WebAuthn API（
navigator.credentials.create()/.get()），跳过密码输入环节，由系统凭证管理器处理认证 - 在可信上下文（如 iframe sandbox + document.domain 隔离）中嵌入独立密码输入组件，限制父页面 JS 访问其 DOM
注意：WebAuthn 不依赖密码，但需浏览器支持（Chrome 67+、Firefox 60+、Safari 14.1+），且服务端必须实现 FIDO2 协议解析。
必须同步做的后端与传输层加固
前端再怎么“伪装”，若后端没跟上，一切白搭。关键动作有：
- 强制全站 HTTPS：否则任何前端加密都会在传输层被降级为明文
- 提交时使用
POST（勿GET），且在服务端立即清空请求体中的密码字段（避免日志落盘） - 服务端收到后，不做明文存储，必须用
Argon2id或bcrypt（$2b$）哈希，且 salt 每次随机 - 登录成功后颁发短期 JWT，并绑定设备指纹/IP/UA，支持主动吊销
一个常被忽略的细节：某些老旧 CDN 或反向代理会缓存含密码的 POST 请求体（尤其当响应头漏设 Cache-Control: no-store），这会让密码意外留存于边缘节点。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
