原生表单提交扛不住高并发，因其同步阻塞、页面刷新、状态耦合导致重复提交与错误覆盖；应改用 formaction 拆分操作意图，结合前端状态机管控按钮可用性，并向后端传递带上下文的操作指令而非原始字段。
为什么原生表单提交扛不住高并发场景
原生 <form> 提交本质是同步阻塞式请求，每次点击都触发完整页面跳转或刷新；在并发量稍大（比如 50+ 用户同时提交）时，loading 状态无法隔离、错误提示覆盖、重复提交拦截失效，后端收到的可能是大量结构一致但语义冲突的请求（如“禁用用户”和“重置密码”混在同一时间窗口）。这不是前端写法问题，而是交互模型与业务意图不匹配。
用 formaction 拆分操作意图，避免状态耦合
不要把“禁用”“导出”“发送通知”全塞进一个 <form> 里靠 JS 切换 action。浏览器原生支持为每个 <button type="submit"> 单独指定 formaction，这样每个按钮天然对应一个独立后端端点，且无需 JS 就能降级运行：
<form id="userForm"> <input name="id" value="123" type="hidden"> <button type="submit" formaction="/api/users/123/disable" name="op" value="disable">禁用</button> <button type="submit" formaction="/api/users/123/export" name="op" value="export">导出数据</button> </form>
-
formaction的值必须是绝对路径（如/api/...），相对路径在多层路由下极易拼错 - 每个按钮的
name和value仍会随请求发出，后端可据此判断操作类型，不必依赖 URL 路径解析 - 若需携带额外字段（如导出格式），直接加
<input type="hidden" name="format" value="xlsx">，它会自动参与该按钮的提交序列化 - 注意：Safari 对
formaction的fetch()兼容性差，纯 JS 提交时别混用
前端状态机只管“按钮可用性”，不碰业务逻辑
复杂表单的状态爆炸不在字段值，而在操作权限流——比如“禁用”按钮必须等“校验通过”且“非管理员”才可点，“导出”则需“至少选中一项”。这类规则不该散落在各个事件监听里，而应集中建模：
- 定义最小原子状态：
idle、validating、ready、pending、error - 每个按钮绑定一个状态谓词，例如禁用按钮的启用条件是
state === 'ready' && !isSuperAdmin - 状态变更只由明确事件触发：表单字段 change → 触发校验 → 校验完成 → 更新状态；按钮 click → 发起请求 → 请求返回 → 更新状态
- 别在状态机里做异步请求，只负责流转；请求交给独立 service 层处理，否则状态和副作用缠绕，调试时根本分不清是网络超时还是状态没更新
后端状态机必须接收“操作意图+上下文快照”，而非原始表单数据
前端提交的不是一堆字段，而是带上下文的操作指令。比如用户点击“升级 VIP”，后端不能只收 {id: 123, plan: "vip"}，而应收到：
立即学习“前端免费学习笔记（深入）”；
{
"op": "upgrade_vip",
"context": {
"user_id": 123,
"current_plan": "basic",
"last_login_at": "2026-06-15T08:22:14Z",
"ip": "192.168.1.100"
},
"timestamp": 1718650334
}
- 前端在提交前用
new FormData(form)收集所有字段，再包装成标准操作 envelope，避免后端从不同字段名里拼逻辑 - 关键字段（如
user_id）必须出现在context中，防止因前端漏传导致状态误判 - 时间戳和服务端校验差值（建议 ≤ 30s），用于识别重放攻击或时钟漂移，这是并发场景下防重复的关键一环
- 后端状态机收到后，先查当前实体状态，再比对
context.current_plan是否匹配，不匹配则拒绝，而不是强行覆盖
真正难的不是写状态流转代码，而是定义清楚哪些状态转移是允许的、哪些必须拒绝、哪些要留审计日志——这些规则一旦上线就很难改，前期花半天画状态图，比后期线上修 bug 强十倍。
