<input type="password">的真实作用仅是前端渲染层遮蔽，将输入字符显示为●或•，不加密、不防抓包、不阻止JS读取明文；安全依赖HTTPS传输与服务端哈希存储。

input type="password 不保护密码可见性，它只遮蔽页面上的显示。

真正能防止他人“看见”密码的，是 HTTPS 传输 + 后端哈希存储，而不是这个标签本身。

---

input type="password 的真实作用是什么

• 它只是告诉浏览器：“别把用户打的字显示出来”，渲染层替换成 ● 或 •，仅此而已
• DOM 中 value 属性始终是明文，document.getElementById('pwd').value 一秒就能读出来
• 表单提交时，字段值仍是原始字符串，如果走 HTTP，抓包工具里直接看到 password=123456
• 它不加密、不哈希、不防 XSS、不阻止开发者工具查看，也不影响网络传输内容

常见误判：

html-to-pptx-converter

使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。

下载

• 把它当安全边界，结果后端没校验、没哈希，数据库里存的全是明文
• 在 URL 里用 GET 提交密码，比如 ?password=xxx，日志、代理、浏览器历史全留痕
• 以为加了 autocomplete="off" 就能阻止浏览器填充，但 Chrome/Edge/Firefox 基本无视这个值

---

为什么移动端粘贴经常失败

• iOS Safari 和部分 Android WebView 对 type="password" 主动禁用长按粘贴菜单，这是系统级限制，不是 bug
• 用户从密码管理器复制长密码时卡住，容易退而求其次设个 123456
• spellcheck="false" 和 autocapitalize="none" 能减少键盘干扰，但解决不了粘贴禁用
• 临时解法：加“显示密码”按钮，切换 type 为 "text"；稳妥做法是初始用 type="password"，点击再切，且切换后不长期保留明文在 DOM 中

---

autocomplete 属性怎么设才有效

• autocomplete="off" 在密码字段上基本无效，现代浏览器会忽略
• 改用 autocomplete="new-password"，明确提示浏览器“这是新密码，别填旧值”
• 如果页面有两个密码字段（如注册页的“新密码”和“确认密码”），两个都得设 autocomplete="new-password"，否则第二个可能被自动填成第一个的值
• 避免 name="password" 或 id="pwd" 这类语义化太强的命名，有些浏览器会主动匹配并填充；可考虑 name="user_auth_token" 这类非标准名（但后端接收字段名也得同步改）

最常被忽略的一点：密码框的 name 属性值，就是 POST 请求里字段的 key，后端靠它取值——起名不能只图方便，得兼顾安全策略和兼容性。

立即学习“前端免费学习笔记（深入）”；