formmethod不参与鉴权，仅控制表单提交的HTTP方法；微前端中真实请求由JS主动发起，绕过原生formmethod，鉴权依赖请求头、路径匹配、Token携带及后端过滤器顺序。
formmethod 本身不参与鉴权，它只是控制表单提交时的 HTTP 方法（如 GET 或 POST），在微前端架构下，它甚至常被绕过——真实请求往往由 JS 主动发起，formmethod 只剩语义或降级兜底作用。真正决定接口是否被放行、是否携带有效凭证、是否触发权限拦截的，是请求头、路径匹配、Token 携带方式和后端认证过滤器的顺序。
为什么 formmethod 在微前端里基本失效
微前端中，子应用通常通过 JS 控制路由与数据请求，而非原生表单提交。即使写了 <form formmethod="POST" action="/api/save">，主应用或子应用的路由拦截、API 封装层（如 axios 拦截器）大概率会捕获该 submit 事件并转为 fetch / axios 调用，此时 formmethod 和 action 都不再生效。
更关键的是：formmethod 不影响请求头、不携带 Token、不触发前端权限校验逻辑，它无法告诉网关“这个请求需要校验 RBAC 权限”或“请附上 Bearer Token”。它只负责浏览器默认行为下的方法选择。
- 用户点击提交 → 浏览器按
formmethod发起原生请求 → 绕过所有 JS 权限拦截逻辑 → 直达网关/后端 - 若未配置 CORS 或未启用 CSRF 保护，这种请求极易被伪造（如钓鱼页面诱导提交）
- 微前端主应用通常禁用原生表单提交，统一走
fetch+ 自定义 header + 权限 code 校验
微前端中真正起作用的鉴权入口点
实际鉴权发生在三个层面，formmethod 不在其中任何一层：
PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。
立即学习“前端免费学习笔记（深入）”；
-
主应用 API 拦截器：所有子应用发起的
fetch/axios请求，统一经过主应用封装的 request 方法，自动注入Authorization: Bearer <token>和权限码（如X-Permission-Code: hiam.permission-demo.save） -
网关路由鉴权：BFF 层（如 Spring Cloud Gateway）根据 path 匹配规则，调用
check-permissions接口，传入当前用户 ID 和请求权限 code，返回{approve: false, controllerType: "hidden"} -
后端 SecurityFilterChain：Spring Security 3.2.9 的自定义
JwtAuthenticationFilter在UsernamePasswordAuthenticationFilter之前执行，识别Authorization头并完成认证；无 Token 时才交由表单登录流程处理
formmethod 可能引发的安全陷阱
当团队误以为 “用了 formmethod="POST" 就比 GET 安全”，或保留原生表单作为兼容方案时，容易暴露漏洞：
- 未禁用原生 submit 的子应用，可能跳过主应用的 token 注入和权限 code 拼装逻辑，导致请求无认证头
- 后端仅校验
POST /api/save的角色，却没校验具体操作权限 code，攻击者可复用合法 Cookie 直接 POST 提交 - CSRF 保护缺失：若后端依赖 Session + Cookie 认证，但没校验
X-CSRF-TOKEN或 SameSite Cookie 策略，原生表单提交极易被跨站利用 - 前端隐藏按钮 ≠ 权限控制：即使菜单里没“保存”按钮，攻击者仍可构造原生
<form method="POST" action="/api/save">提交
正确做法：彻底放弃对 formmethod 的信任
微前端架构下，鉴权必须前置、显式、可审计，不能依赖 HTML 属性：
- 所有子应用发请求必须走主应用提供的
request()函数，禁止直接使用fetch或XMLHttpRequest - 主应用 request 拦截器强制添加
Authorization和X-Permission-Code，缺失则拒绝发出 - 后端
check-permissions接口必须同步校验权限 code 与当前用户 session / token 的绑定关系，不能只查 DB 角色 - 若需保留原生表单降级能力，应在主应用监听
submit事件，阻止默认行为，转为受控请求，并注入必要鉴权字段
真正的安全边界不在 formmethod，而在请求发出前是否被主应用统一治理、是否携带不可伪造的上下文标识、以及后端是否对每个操作级权限做实时校验。这点在 Spring Security 3.2.9 的双认证架构里尤为关键——Token 过滤器和表单过滤器共用同一套 AuthenticationManager，但权限决策必须落在更细粒度的 AccessDecisionManager 或自定义 FilterInvocationSecurityMetadataSource 上，而不是靠提交方式区分。
