formaction 属性通过为不同按钮设置独立提交路径（如 /api/approval/accept 和 /api/approval/reject），使同一表单的“同意”“驳回”操作天然映射到不同后端接口，无需javascript，语义清晰且复用全部字段。
formaction 属性怎么映射不同审批操作？
直接用 formaction 实现“同意”“驳回”走不同后端接口，是最轻量、最符合语义的方案——不用写 JS 绑定事件，也不用拆成多个表单。关键在于：每个 <button></button> 或 <input type="submit"> 可独立指定提交地址，浏览器会忽略表单自身的 action，以点击按钮的 formaction 为准。
常见错误是把 formaction 写在 <form></form> 上（无效），或混用 onclick + fetch 破坏了原生表单的可访问性和降级能力。
-
formaction必须写在可提交的控件上，即<button type="submit"></button>或<input type="submit"> - 路径必须是完整 URL 或相对路径（如
/api/approval/accept），不能是函数名或变量名 - 所有按钮共享同一组
<input name="...">字段，后端靠路径区分行为，不是靠额外参数
如何保证提交数据一致且不重复？
多个 formaction 按钮共用一个表单，天然复用全部字段值——这是优势，也是陷阱。如果某字段只在“同意”时需要、驳回时不该传，就不能靠前端隐藏/移除 DOM，而要让后端根据接口路径做字段校验或忽略逻辑。
例如：审批意见字段 comment 在驳回时必填，同意时可选。此时不要用 JS 动态增删 input，否则易出错且破坏表单完整性。
- 所有业务字段统一放在表单内，保持结构稳定
- 用
required属性配合formaction不起作用——HTML5 校验只看当前表单，不管最终提交到哪；必须由后端按路径做差异化校验 - 若需前端提示差异，可用
button的data-xxx属性辅助，比如data-required-fields="comment,reason"，再配极简 JS 做提交前检查（非必需）
为什么 formaction 提交后页面跳转了？
默认行为就是跳转——这恰恰是它的设计目的：简单审批操作完成后，后端返回 HTML 页面（如“已同意”成功页），用户立刻看到结果。如果你希望无刷新，说明你其实不需要 formaction，该换 fetch + 手动控制。
强行阻止跳转（如 event.preventDefault()）会让 formaction 失效，变成无效按钮。
- 接受跳转：后端返回
text/html，适合管理后台类应用 - 拒绝跳转：改用
fetch调用对应接口，此时formaction退化为纯语义占位，实际逻辑由 JS 承担 - 混合策略：同意走
formaction跳转，驳回用 JS 弹窗确认后再fetch，但要注意 UX 一致性
兼容性与服务端注意事项
formaction 是 HTML5 标准属性，IE10+ 和所有现代浏览器都支持，无需 polyfill。真正容易被忽略的是服务端路由和 CSRF 处理。
两个接口（如 /api/approval/accept 和 /api/approval/reject）必须：共用同一套表单字段解析逻辑、校验相同 token、返回一致的状态码规范。否则前端看似简洁，后端却要维护两套几乎重复的接收逻辑。
- Spring Boot 示例：用
@PostMapping("/api/approval/{action}")+@PathVariable统一路由，再分支处理 - Django 示例：URL pattern 写成
path('api/approval/<action>/', ...)</action>，视图里判断action in ['accept', 'reject'] - CSRF token 必须随表单一起提交（
<input name="csrf_token" value="...">），且两个接口都校验它——别漏掉其中一个
多接口映射本身很简单，难的是后端是否真按“同一业务动作的不同分支”来设计，而不是当成两个孤立接口硬塞进去。
