https是唯一可靠的数据加密传输方式；其他前端加密无效或易出错，type="password"仅掩码显示，formdata修改无效，web crypto需https，服务端必须哈希明文密码。
表单数据加密不是靠 <form></form> 标签或 type="password" 实现的，真正起作用的只有 HTTPS；其他所谓“前端加密”要么无效，要么容易翻车，必须清楚边界。
HTTPS 是唯一可靠的数据加密传输方式
浏览器提交表单时，无论 method="GET" 还是 method="POST"，所有字段（包括 password）在网络层都是明文——除非走 HTTPS。HTTP 协议本身不加密，攻击者用 Wireshark 或代理工具就能直接看到 username=admin&password=123456。
- 检查地址栏是否为
https://，且锁图标为绿色、显示“安全” - 确保整个页面由 HTTPS 加载（避免混合内容：HTTPS 页面里引入 HTTP 脚本会触发浏览器拦截）
- 后端反向代理（如 Nginx）配置了 HTTPS，但 upstream 转发到
http://localhost:3000？那只是 TLS 终止在代理层，内网仍是明文 - 自签名证书、过期证书或域名不匹配，在现代浏览器（尤其 iOS Safari）中会导致表单提交被静默拒绝或自动降级
前端 JS 加密不能替代 HTTPS，且极易误用
有人用 JSEncrypt 或 Web Crypto API 在提交前加密密码字段，这看似多一层防护，但实际引入新风险：JS 代码和公钥都暴露在客户端，攻击者可篡改逻辑、跳过加密、或伪造解密响应。更关键的是，常见错误写法根本不会生效。
- 错误做法：
new FormData(form).set('password', encrypted)——FormData是只读快照，修改它不影响真实提交值 - 正确做法：必须直接覆写 DOM 元素的
value，例如document.getElementById('password').value = encrypted - 即使加密成功，服务端收到的仍是密文，仍需再次用
bcrypt或Argon2哈希存储，绝不能把前端密文当最终凭据 -
Web Crypto API（如SubtleCrypto.encrypt()）只能在 HTTPS 页面中调用，HTTP 下直接报错
type="password" 不是加密，只是视觉掩码
<input type="password"> 只控制输入框显示为圆点，对传输和存储毫无保护作用。DOM 中 input.value 仍是明文，Network 面板里 POST body 也清清楚楚写着 password=xxx。
- 不要用
btoa()或atob()“伪装”加密——Base64 不是加密，解码瞬间还原 -
autocomplete="new-password"比"off"更有效，能减少浏览器自动填充旧密码的风险 - 移动端需加
autocapitalize="none" autocorrect="off"，防止 iOS 键盘误开大写或拼写纠正干扰密码 - 服务端收到的永远是原始字符串，必须立刻哈希，绝不存明文、不打日志、不透出响应体
最常被忽略的一点：前端加密掩盖了真正的薄弱环节——比如忘了强制全站 HTTPS、Nginx 配置漏了 HSTS 头、或者测试环境还在用 HTTP 提交生产表单。这些比写十行加密 JS 更致命。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
