必须使用https，否则前端加密无效；密码需后端用bcrypt等慢哈希处理，敏感数据应由服务端密钥aead加密；autocomplete和inputmode仅控输入体验，不提供加密。
html 表单本身不加密数据
浏览器提交表单时，GET 用 URL 传参，POST 用请求体发送，但默认都是明文——哪怕加了 type="password"，也只是遮掩输入框，HTTP 层没加密。真正起作用的是传输层：必须用 https（即 https:// 开头的地址），否则任何“前端加密”都形同虚设，因为 js 代码和密钥全在客户端暴露，攻击者可直接绕过或篡改。
常见错误现象：
– 页面用 http:// 提交，却在 JS 里调用 crypto.subtle.encrypt() 自嗨
– 后端接收后发现解密失败，其实根本没加密，只是前端 log 里写了“已加密”
– 抓包工具（如 chrome DevTools Network 或 wireshark）一眼看到完整用户名密码
- HTTPS 是硬性前提，没有它，其他全是安慰剂
- 证书要有效（不能是自签名且未被信任，也不能过期）
- 确保所有资源（CSS/JS/iframe）也走 HTTPS，否则混合内容会触发浏览器降级或阻断
想在发出去之前做额外加密？别用 base64 或 md5
base64 不是加密，是编码；md5、sha256 是哈希，不可逆，无法还原原始密码——除非你打算把哈希值当密码存进数据库（这违反安全常识）。真要加一层客户端处理，得用非对称加密（如 RSA）或现代 Web Crypto API 的 AES-GCM，但前提是：密钥管理有方案，且后端能配合解密。
使用场景极少，典型只出现在某些合规要求“双因子+本地加密”的金融内网系统，公网网站几乎不需要。
立即学习“前端免费学习笔记（深入）”；
- 前端生成密钥对？私钥一旦落在浏览器里，就等于公开
- 用服务端下发公钥？需防中间人替换，仍依赖 HTTPS
- 性能影响不大，但兼容性要注意：
crypto.subtle在 safari 16.4+ 才支持完整的 AES-GCM - 示例（仅示意流程，非可用代码）：
await crypto.subtle.encrypt({ name: "AES-GCM", iv }, key, encoder.encode("password=123"))
表单字段级控制：autocomplete 和 inputmode 不解决加密，但影响数据泄露面
这些属性不加密，但能减少浏览器自动填充、键盘预测等带来的意外暴露。比如密码字段被 autofill 成明文塞进普通 input type="text"，或手机键盘把银行卡号记进词库。
-
autocomplete="off"对现代浏览器效果有限，更可靠的是设为无意义值：autocomplete="new-password"或autocomplete="cc-number" -
inputmode="numeric"只影响软键盘类型，和加密无关，但能避免用户误输字母导致校验失败 - 敏感字段（如身份证号）建议加
pattern和inputmode双约束，减少无效提交
后端才是加密责任终点
前端无论怎么“加密”，最终都要解密成明文交给业务逻辑。所以关键动作在后端：密码必须用 bcrypt、scrypt 或 Argon2 哈希（带盐、慢哈希）；其他敏感字段（如手机号、地址）若需落库存储，应使用服务端托管的密钥做 AEAD 加密（如 AWS KMS、HashiCorp Vault），而不是硬编码密钥或用前端传来的密钥。
容易踩的坑：
– 用 localStorage 存加密后的 Token，结果 xss 一打就全漏
– 数据库字段用 AES_ENCRYPT() 但密钥写死在 PHP 文件里
– 忘记加密索引字段（如手机号），导致无法高效查询又不敢建明文索引
事情说清了就结束