前端md5加密仅防传输嗅探，不能替代服务端校验；须在onsubmit中替换密码字段、禁用原输入框并阻止默认提交，选用blueimp-md5库，配合https、动态salt二次哈希及一次性token防重放。
前端对密码做 MD5 加密不能替代服务端校验，但能避免明文密码在传输中被直接嗅探。实际操作中，关键不是“能不能加”，而是“加在哪一步、加几次、怎么防篡改”。
用 onsubmit 拦截表单提交并替换密码字段
必须在表单真正发出前把原始 password 输入框的值替换成 MD5 结果，否则后端收到的仍是明文。常见错误是只改了隐藏域却没禁用原密码输入框，或忘了 return false 阻止默认提交。
- 给密码
<input type="password">设一个 ID（如id="pwd"），方便 JS 获取值 - 添加一个
<input type="hidden" name="password">，name 与后端接收字段一致 - 在
<form onsubmit="return encryptAndSubmit()"> 中调用函数，返回 <code>false阻止重复提交，返回true才真正发请求 - 函数内先计算
md5(pwd.value)，再赋给隐藏域md5pwd.value = md5(pwd.value)，最后清空原密码框或设为disabled
选对 MD5 库：优先用 blueimp-md5 而非 CryptoJS
CryptoJS 体积大、依赖多，且默认导出方式在现代 HTML 中容易报 CryptoJS is not defined；blueimp-md5 是轻量纯函数库，CDN 加载即用，兼容性更好。
- 引入方式：
<script src="https://cdn.bootcdn.net/ajax/libs/blueimp-md5/2.19.0/js/md5.min.js"></script> - 调用方式极简：
md5("123456")直接返回 32 位小写十六进制字符串 - 不支持中文自动编码，若密码含中文，需先用
encodeURIComponent处理，否则结果不一致
防止重复提交和中间人篡改的硬性配套动作
仅加密密码远远不够。用户连点两次“登录”按钮，可能发出两个相同请求；攻击者抓包重放加密后的密码，也能绕过前端逻辑。必须叠加防护。
- 提交后立即将按钮设为
disabled：document.querySelector('button[type="submit"]').disabled = true - 配合一次性 token：服务端下发
token放入隐藏域，提交时一并发送，后端校验并立即作废 - 禁止在 URL 中传密码：
method="post"必须明确指定，不要用get；action地址不能带敏感参数 - 前端加密后仍要清空原始密码框值，避免用户刷新页面后意外二次提交
MD5 不等于安全：别跳过服务端二次哈希和 salt
前端 MD5 只是第一道掩护，它解决不了数据库泄露后的彩虹表攻击。服务端必须做两件事：加随机 salt 再哈希一次，且不能复用前端传来的 MD5 值直接存库。
- 正确流程：前端传
md5(明文 + 固定前端 salt)→ 后端取该值 + 用户专属随机 salt → 再算一次md5()或改用bcrypt/scrypt存储 - 如果后端直接把前端 MD5 结果当最终密码存，等于把“密码等价物”明文入库，毫无意义
- HTTPS 是前提——没有 TLS，前端任何加密都白搭，因为整个请求体可被中间人替换
最容易被忽略的是前后端 salt 的分工：前端固定 salt 只防抓包明文，后端动态 salt 才防撞库。两者缺一不可，且绝不能混用同一个值。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
