点击label嵌套input时触发两次click是W3C规范行为：label激活控件导致input自身再触发一次；应将事件绑定到input上，或用for/id平级结构避免歧义。
label 嵌套 input 时点击触发两次，不是 bug，是浏览器按 W3C 规范执行的语义激活行为：点击文字 → 激活关联控件 → 控件自身也触发一次 click。直接在 label 上绑 click 事件，大概率会出问题。
为什么必须区分 event.target 是 label 还是 input
当你监听的是父容器（比如 div#form）的 click，而里面既有 label 又有它关联的 input，那么一次点击会产生两个冒泡路径：一个是 label → div，另一个是 input → div。控制台打印 event.target.nodeName 会看到先后输出 LABEL 和 INPUT。
常见错误现象包括：复选框状态翻转两次、React/Vue 中 setState/v-model 被调用两次、接口重复提交。
- 只判断
event.target === e.currentTarget不够，因为两次事件都发生在同一个监听器里 - 不能只靠
e.stopPropagation()写在label上——第一次冒泡已经完成，写在label上无效 - 写在
input上才有效，但前提是事件确实绑定到了input
把 click 事件移到 input 上是最简方案
绝大多数场景下，你真正想响应的是“控件状态变化”，而不是“用户点了哪块区域”。所以直接把事件处理器挂到 input 元素上，既符合语义，又天然避开双触发。
立即学习“前端免费学习笔记（深入）”；
示例（原结构）：
<label><input type="checkbox"> 我同意</label>
改为：
<label for="agree">我同意</label><input type="checkbox" id="agree" onclick="handleAgree()">
或 Vue 中：
<input type="checkbox" @click="handleAgree" v-model="isChecked"><label for="agree">我同意</label>
- 注意
for和id必须严格匹配，否则可访问性受损 - 如果用了
v-model，@change比@click更稳妥，因它只在值真实改变后触发 - 不要在
label和input上同时绑相同逻辑的click，这是冲突源头
必须保留嵌套结构时，用 stopPropagation + 判断 target
有些 UI 组件库或遗留代码强制要求 input 在 label 内部（比如为了样式覆盖或 focus 样式统一），这时只能干预事件流。
关键点：event.stopPropagation() 必须写在 input 的事件处理器里，且要早于任何业务逻辑：
<label><input type="radio" onclick="event.stopPropagation(); handleSelect()" name="opt"> 选项A</label>
或者用 JS 绑定：
document.querySelectorAll('label input').forEach(el => { el.addEventListener('click', e => { e.stopPropagation(); handleSelect(); });});
- 写在
label的onclick里完全没用，因为第一次冒泡已经向上走了 - 不要依赖
setTimeout或时间戳去“防抖”——这掩盖问题，且在快速连点或自动化测试中仍可能失败 - 如果用了 jQuery，
$(el).on('click', 'input', handler)这种委托写法，也要确保 handler 里调用了e.stopPropagation()
for 属性平级结构是长期维护最优解
语义清晰、无障碍友好、无事件歧义、CSS 选择器更可控——所有现代框架文档和 WCAG 指南都推荐这种写法。
结构必须是：
<input id="chk1" type="checkbox"><label for="chk1">选项文本</label>
而不是：
<label for="chk1"><input id="chk1" type="checkbox">选项文本</label>
-
for属性值必须与input的id完全一致（区分大小写） - 若
input动态生成，务必同步设置id，否则屏幕阅读器无法关联 - 某些旧版 IE 对
for支持不完整，但 IE 已退出主流支持，2026 年无需再为它妥协
真正容易被忽略的点是：这个双触发问题在 SSR 渲染或服务端模板里不报错、不警告，只有用户交互时才暴露，且在自动化测试中若没断言事件次数，很容易漏掉。别等上线后被反馈才修。
