判断表单提交前数据被js修改，需检查submit事件监听器、input/change/blur事件绑定、formdata或urlsearchparams手动构造、Event.preventdefault()使用及hidden字段动态计算等关键点。
怎么判断表单提交前数据被 JS 修改过
直接看 submit 事件监听器和 form.onsubmit，但更关键的是检查有没有在 input/select 等元素上绑了 change、input 或 blur 事件，悄悄改了 value 或 dataset。
常见错误现象：后端收到的字段值和页面上看到的不一致；调试时打断点发现 event.target.value 是旧值，但提交时却变了。
- 用浏览器开发者工具的
Elements面板右键目标输入框 →break on > Attribute modifications，触发修改就能停住 - 在控制台执行
getEventListeners(document.querySelector('form'))查看所有绑定的事件（注意：仅限当前选中节点） - 重点关注是否调用了
FormData.append()或手动拼接URLSearchParams—— 这类代码常绕过 dom 值，直接塞进提交载荷
抓包时发现请求体字段和表单 DOM 对不上怎么办
说明数据没走原生表单序列化，而是被 JS 拦截后重构造了。原生 form.submit() 不会触发 submit 事件，但 event.preventDefault() + fetch() 一定会绕过 DOM 同步状态。
使用场景：登录表单加了密码 AES 加密、手机号自动补区号、隐藏字段动态注入 Token。
立即学习“前端免费学习笔记（深入）”；
- 检查是否有
event.preventDefault()出现在submit回调里 - 搜索代码里的
new FormData(—— 它读取的是当前 DOM 的value，但如果之前 JS 已经改过input.value，那它读到的就是被改过的 - 留意
form.getAttribute('action')和实际fetch()地址是否不同，这是典型的手动提交迹象
chrome DevTools 怎么监控表单字段实时变更
靠 console.log 打点太被动，得用 MutationObserver 监听 value 属性变化，或者更直接——在 input 元素上设 DOM 断点。
性能影响很小，但要注意兼容性：MutationObserver 在 IE 中不可用，不过审计时通常只关心现代浏览器行为。
- 在 Elements 面板选中一个
input，右键 →Break on > attribute modifications，改值就会暂停 - 粘贴这段脚本到 Console 快速监听所有文本类输入框：
document.querySelectorAll('input[type="text"], input[type="password"], textarea').forEach(el => el.addEventListener('input', e => console.log('修改:', e.target.name, '→', e.target.value))) - 不要只盯
value，有些逻辑写在data-*属性里（比如data-encrypted="true"），也得一并看
后端验签失败但前端表单看着没问题，问题可能出在哪
签名原文很可能不是你看到的表单 html，而是 JS 拼出来的字符串、对象或 base64 片段。尤其是当有“防篡改 hidden 字段”时，它的值往往由 JS 计算生成，而非服务端下发。
容易踩的坑：以为 hidden input 的 value 是静态的，其实它可能在 submit 前被 sha256(json.stringify(formData)) 之类逻辑覆盖。
- 搜索代码里的
crypto.subtle.digest、sha256、hmac、btoa(等关键词 - 检查是否有
form.addEventListener('submit', ...)里调用了异步操作（比如等加密完成才发请求），这种会导致 race condition，抓包看到的可能是未加密原始值 - 注意
disabled的表单项不会被FormData收集，但 JS 可能手动把它加进去 —— 此时 DOM 看着是禁用，实际参与了签名
事情说清了就结束