<input type="password">仅实现UI遮掩，不加密、不防抓包，提交值仍为明文；必须依赖HTTPS传输、后端校验与服务端逻辑防护，前端遮掩仅为用户体验。
html 的 <input type="password"></strong> 本身不加密、不隐藏逻辑、不防抓包，它只做一件事：在页面上把输入内容显示为圆点（•）。</p>
<H3>为什么输密码时看到的是圆点，但别人还是能拿到明文？</H3>
<p>因为 <code>type="password"
只是浏览器的 UI 行为，表单提交时值仍是原始字符串。只要打开开发者工具，在 Elements 面板里双击 value 属性，或者在 Console 里执行 document.querySelector('input[type="password"]').value，立刻就能看到明文。
常见错误现象：
– 后端没校验，前端“以为加了 password 就安全了”
– 把敏感操作（如删除账号）仅靠前端 type="password" 确认，绕过输入也能提交
– 在 URL 中拼接密码（GET 请求），导致密码出现在日志、代理、历史记录里
- 真正保护密码，必须走 HTTPS（否则 HTTP 明文传输，连圆点都救不了你）
- 密码字段必须配合后端验证，不能只依赖前端遮掩
- 敏感操作要服务端二次确认，比如用 token 或 session 绑定动作，而不是只靠一个密码框
autocomplete="off" 真的能关掉密码记忆吗？
不能完全关掉。现代浏览器（Chrome、Edge、Firefox）对 autocomplete="off" 在密码字段上基本无视——它们会优先按自己的策略判断是否保存。更可靠的做法是用语义化属性：
- 用
autocomplete="new-password"告诉浏览器：“这是新密码，别填旧的，也别存它” - 避免给密码框起名像
name="password"或id="pwd"，有些浏览器会主动匹配并填充；可考虑name="user_auth_token"这类非标准名（但需同步改后端接收逻辑） - 如果页面有多个密码字段（如注册页的“新密码”+“确认密码”），两个都设
autocomplete="new-password"，否则第二个可能被自动填充第一个的值
移动端软键盘弹出密码模式，但用户粘贴失败怎么办？
部分 Android 浏览器或 iOS Safari 对 type="password" 会禁用长按粘贴菜单，尤其在 WebView 或 PWA 中更明显。这不是 bug，是系统级安全限制。
立即学习“前端免费学习笔记（深入）”；
使用场景：
– 用户想从密码管理器粘贴生成的长密码
– 测试时反复输入同一串字符
- 临时方案：加一个“显示密码”按钮，切换
type为"text"（注意切换时不要暴露 DOM 中的明文 value） - 更稳妥做法：用
type="text"+ CSS 模拟圆点（text-security: disc，但兼容性差，iOS 不支持） - 底线原则：别为了“看起来更安全”而牺牲可用性——用户因无法粘贴，反而会设置弱密码或写在便签上
最常被忽略的一点：密码框的 name 属性值，会直接作为 POST 请求的 key 发送到后端。如果写成 name="password"，攻击者扫到接口就能猜字段含义；换成 name="auth_key" 这类泛化名，至少增加一点分析成本。但这只是混淆，不是防护——真正的防护永远在 HTTPS + 服务端校验 + 不明文落库。事情说清了就结束。
