仅实现前端掩码显示，不加密；明文仍存于DOM、HTTP明文传输（需HTTPS）、服务端须立即哈希存储（如bcrypt），base64等非加密，安全防线在HTTPS、服务端哈希、数据库隔离。
html 表单里的 <input type="password"> 本身不加密，它只是前端掩码显示——输入内容在页面上被替换成圆点，但原始值仍以明文形式存在于 dom 和网络传输中。
为什么 <input type="password"> 看起来“安全”其实是假象
浏览器用这个类型只是为了视觉遮蔽，document.getElementById('pwd').value 依然能直接拿到明文；表单提交时若没走 HTTPS，密码会以纯文本发到服务器；服务端收到的也还是明文，没自动加盐、哈希或 AES 加密。
常见错误现象：console.log(document.querySelector('input[type=password]').value) 打印出真实密码；抓包工具（如 Chrome DevTools 的 Network 面板）看到 POST 请求体里明文出现 password=123456。
- 它不参与任何加密流程，不是密码学意义上的“加密”
- 不能替代服务端的密码哈希（如 bcrypt、Argon2）
- 也不解决中间人攻击——必须配合 HTTPS
真正要防什么？关键在传输和存储环节
用户输密码时，你唯一可控的“加密动作”只有两处：一是确保传输加密（HTTPS），二是服务端立即哈希存储。前端 JS 手动加密（比如用 CryptoJS）反而容易引入漏洞或误导。
使用场景：登录、注册、修改密码等表单提交。
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
立即学习“前端免费学习笔记（深入）”；
- 强制全站 HTTPS：否则
<input type="password">就是裸奔 - 服务端收到
password字段后，立刻用 bcrypt 对其哈希，存哈希值而非明文 - 不要在前端用
atob()、btoa()或简单 base64 做“伪装”——base64 不是加密，解码秒出明文 - 避免在 URL 参数里传密码（如
?password=xxx），GET 请求会被日志、代理缓存
autocomplete="off" 和 autocapitalize="none" 这些属性有用吗？
有用，但只影响体验和基础防护，和加密无关。它们是防止浏览器自动填充或首字母大写干扰密码大小写敏感性。
参数差异：autocomplete 在现代浏览器中对 type="password" 效果有限，部分浏览器仍会提示保存；autocapitalize="none" 主要用于 iOS 键盘，避免误开大写。
- 加
autocomplete="new-password"比"off"更可靠，告诉浏览器这是新密码字段，别填旧值 - 移动端尤其注意：iOS Safari 对
autocapitalize和autocorrect="off"响应更明显 - 不要依赖这些属性防 XSS 或调试窥探——DOM 里 value 始终可读
最常被忽略的一点：很多人以为加了 type="password" 就算“做了安全处理”，其实它连最小的安全边界都没建立。真正的防线在 HTTPS 连接、服务端哈希、数据库权限隔离这三环，缺一不可。
