浏览器按DOM顺序将同名表单控件的值拼为“key=value&key=value”格式提交；服务端需统一处理多值（如转数组校验），避免覆盖或解析不一致，且须防范前端绕过导致的重复参数。
name属性重复时浏览器如何组装表单数据
当多个 <input>、<select> 或 <textarea> 共享同一个 name 时，浏览器不会报错，也不会忽略后续项——它会按 DOM 顺序将所有同名控件的值拼成一个列表，用 & 符号连接后提交。比如两个 name="tag" 的复选框分别选中 "a" 和 "b"，最终发送的是 tag=a&tag=b，服务端收到的就是数组或重复键值对。
这在多数后端框架中是受支持的：PHP 的 $_POST['tag'] 是数组；Node.js 的 body-parser 默认解析为数组（需启用 extended: true）；Spring Boot 的 @RequestParam List<String> 也能自动绑定。
- 单选按钮（
type="radio"）天然依赖同名来实现互斥，这是合法且必须的用法 - 复选框（
type="checkbox"）也常靠同名收集多选结果 - 但文本输入框、下拉框等若意外重复
name，会导致数据覆盖或混乱（如后一个name="email"覆盖前一个）
id重复不影响提交，但破坏可访问性与JS选择器
id 属性重复完全不影响表单数据提交——因为提交只认 name。但它是严重 HTML 违规：W3C 要求全局唯一，Lighthouse 会标为可访问性失败，document.getElementById() 只返回第一个匹配元素，<label for="xxx"> 点击可能聚焦错误输入框。
尤其在响应式场景中，桌面版和移动版共存同一页面时，容易因复制粘贴导致 id 冲突。此时必须差异化命名，例如 email-desktop 和 email-mobile，同时保持 name="email" 不变。
立即学习“前端免费学习笔记（深入）”；
- 无障碍要求：每个
<label for="">必须指向唯一id，否则屏幕阅读器行为不可预测 - JS 绑定风险：若用
querySelector('#submit-btn')控制按钮状态，而页面存在两个id="submit-btn"，结果不可控 - 不要依赖
id做表单校验逻辑，优先用name或更健壮的选择器（如form[data-type="login"] input[name="password"]）
name相同但类型混用时的常见陷阱
当同名控件类型不一致（例如一个 text 输入框 + 一个 hidden 输入框都叫 user_id），浏览器仍会全部提交，但服务端解析可能出问题：某些框架只取第一个值，有些则合并为数组，行为不统一。
更隐蔽的问题是动态插入表单控件时未清理旧节点——比如 JS 模板反复渲染，每次 append 一个 name="phone" 的 <input>，却没 remove 之前的，最终提交一堆重复字段。
- 避免跨类型混用同名控件，尤其不要让
text和hidden共享name - 使用 JS 动态生成表单时，先清空容器或用
replaceChildren()替换整个内容，而非无条件append() - 调试时可用
new FormData(form).entries()在控制台快速查看实际提交内容，比猜更可靠
服务端如何安全处理同名多值
不能假设客户端只发一个值。即使前端 UI 上只允许单选，用户仍可通过 DevTools 修改 HTML 或用 curl 手动构造请求发送多个同名参数。
所以服务端校验逻辑要明确：是接受单值（取第一个）、允许多值（校验每个）、还是严格拒绝多值？比如邮箱字段若收到两个 email=foo@ex.com&email=bar@ex.com，应直接 400 报错，而不是取第一个了事。
- Node.js + Express：用
req.body.email可能是字符串或数组，建议统一转为数组再校验：Array.isArray(req.body.email) ? req.body.email : [req.body.email] - Java Spring：用
@RequestParam(required = false)接收为List<String>，再判断 size 是否为 1 - PHP：
is_array($_POST['email'])判断，避免直接$_POST['email'][0]导致 Notice
name，父组件又传了一次，或者国际化切换时重新挂载表单却忘了清理旧 DOM。每次上线前用 document.querySelectorAll('[name]') 扫一遍，比等用户投诉后再查日志快得多。 
