type="password"仅遮掩UI，安全依赖传输、存储和交互逻辑；autocomplete="new-password"比"off"有效因浏览器忽略后者；密码明文易在DOM、GET请求、HTTP中泄露，须服务端校验、POST提交、HTTPS加密。
type="password" 本身不保障安全，它只做 UI 遮掩。真正起作用的是你如何用它配合传输、存储和交互逻辑。
为什么 autocomplete="new-password" 比 autocomplete="off" 有效
现代浏览器（Chrome、Edge、Firefox）基本忽略 autocomplete="off"，尤其在 type="password" 场景下——它们会按自身策略决定是否填充。而 autocomplete="new-password" 是明确语义提示：这是新设密码，不要填旧值、也不存它。
- 注册页或改密页必须用
autocomplete="new-password"，否则第二个密码框（如“确认密码”）可能被自动填入第一个的值 - 登录页应配
autocomplete="current-password"，让密码管理器识别上下文并正确填充 -
autocomplete值区分大小写，new-password写成New-Password或NEW-PASSWORD无效 - 避免
name="pwd"这类模糊命名，优先用name="user_password"或name="auth_token"（需同步改后端接收字段）
密码明文暴露的三个高频入口及应对
开发者常以为加了 type="password" 就安全了，但实际明文在以下三处极易泄露：
htmlppt.skill
下载
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
-
DOM 中可读：执行
document.querySelector('input[type="password"]').value立刻拿到明文 —— 所以敏感操作不能仅靠前端校验，必须服务端二次确认（如删除账号前验证 session + token） -
GET 请求拼接：写成
/login?password=123456会让密码出现在服务器日志、代理缓存、浏览器历史中 —— 必须用method="POST"提交 - HTTPS 缺失：HTTP 下，即使 POST body 里的密码也是明文裸奔 —— 没有 HTTPS，所有前端防护都形同虚设
移动端粘贴失败和软键盘异常怎么修
iOS Safari 和部分 Android WebView 在 type="password" 下禁用长按粘贴，不是 bug，是系统级限制。同时，软键盘不弹出密码模式，往往不是标签写错了，而是渲染环境问题。
- 检查父容器是否用了
transform、opacity: 0或visibility: hidden，这些会让浏览器无法识别输入域有效性 - 确保页面没设
meta name="viewport" content="user-scalable=no"，某些安卓 WebView 会因此降级为文本键盘 - 加
inputmode="text"（虽非必需，但低版本 WebView 更认这个） - 临时方案是加“显示密码”按钮，切换
type为"text"—— 切换时别直接改 DOM 的value，而是用 JS 控制显示逻辑，避免明文残留
最容易被忽略的点：密码强度规则（比如大小写+数字+8位）必须前后端双重校验。pattern 属性只是体验优化，后端没校验等于没设防；而前端用 JS 做 MD5/SHA 加密再提交，反而把哈希值当密码用，放大风险。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
