跨表单提交冲突的两个核心原因是form属性指向错误和同名name字段被覆盖；前者导致按钮提交目标错乱，后者使后端仅接收最后一个同名字段值。
form 属性指向错误或同名 name 字段被覆盖，是跨表单提交冲突的两个核心原因。前者导致按钮“看似提交了A表单，实际发了B表单”，后者让后端只收到最后一个值——问题不报错，但数据总丢。
检查 form 属性是否指向真实存在的 id
用 form="edit-form" 的按钮，必须对应页面中一个 <form id="edit-form"></form>。大小写、连字符、下划线都必须完全一致，浏览器不会做任何容错匹配。
- 打开控制台，运行
document.querySelector('button[form]')找出所有跨表单按钮 - 对每个按钮执行
document.getElementById(btn.form)，返回null就说明目标表单不存在或id不匹配 - 注意：服务端模板（如 EJS、Twig）生成的
id可能带随机后缀或条件拼接，要检查最终 HTML 源码，而非 Elements 面板（后者可能已被 JS 修改）
排查重复 name 字段覆盖问题
浏览器提交时，同名 name 字段只保留 DOM 中最后出现的那个控件的值。radio 和 checkbox 是例外，其余类型重复即危险。
DeepBI DHTML 页面生成器
下载
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 别靠肉眼扫。在控制台粘贴这行代码：
Object.entries(Array.from(document.querySelectorAll('[name]')).reduce((acc, el) => { acc[el.name] = (acc[el.name] || 0) + 1; return acc; }, {})).filter(([_, count]) => count > 1) - 返回非空数组，就列出所有冲突的
name值，比如["email", "phone"] - 特别注意动态插入的表单（Vue/React 组件挂载后才渲染），需等组件就绪再运行检查脚本
- 多选
<select multiple></select>必须带[]后缀（如name="hobbies[]"），否则只传最后一个选中项
修复策略要分场景，不能一刀切
不是所有重复 name 都该删——关键看语义和后端约定。
立即学习“前端免费学习笔记（深入）”；
-
<input type="radio">组必须共用name，这是正确用法；<input type="checkbox">多选也应统一name并加[] - 响应式双表单（桌面+移动端各一套）：保留相同
name（保障后端接收逻辑不变），但id和for必须差异化，如email-desktop/email-mobile - 纯手误复制（如两处都写了
<input name="email">）：直接删掉多余的，或重命名为带上下文的，如contact_email和billing_email - 条件渲染区块（如不同角色表单）：
name必须统一，但 JS 验证逻辑要按区块隔离，避免document.querySelector('[name="email"]')错绑到隐藏区块的控件上
最容易被忽略的是：跨表单提交时，按钮的 formmethod 和 formaction 仅改变请求方式与地址，**不自动过滤字段**。哪怕你只想导出，只要按钮挂在某个 form 下，它仍会把整个表单所有 name 都带上——后端必须做白名单校验，不能只依赖前端隐藏或禁用字段。
