label嵌套input时click触发两次是W3C规范行为：先触发label的click事件，再自动调用input.click()引发第二次冒泡；正确解法是改用for关联或仅在input上用stopPropagation()。
label嵌套input时click触发两次是规范行为，不是bug
点击
常见错误解法包括在label上写onclick="return false"或event.preventDefault()，这会直接禁用默认激活行为（比如复选框不勾选），破坏屏幕阅读器支持。
- 稳妥方案：改用显式
for关联，把input和label写成平级结构：<input id="chk1"><label for="chk1">选项</label> - 必须嵌套时：只在
input上加onclick="event.stopPropagation()"——写在label上无效，因为第一次冒泡已经完成 - 别用
return false，它同时阻止默认行为和冒泡，不可逆地切断可访问性链路
stopPropagation()写了却没用？检查event对象是否真实可用
event.stopPropagation()不是开关，它只在事件处理函数体内、拿到有效event对象时才生效。很多“写了没反应”的情况，本质是event根本没传进来，或者传错了。
典型失效场景：
立即学习“前端免费学习笔记（深入）”；
- 内联写法
onclick="handleClick()"，但handleClick()函数没声明参数，event为undefined - 监听器用
element.onclick = function() {}赋值，没接收参数，无法调用stopPropagation() - 把
event.stopPropagation()放在setTimeout或Promise.then里，事件早已完成冒泡路径 - 拼写错误，比如写成
ev.stopPropagation()但实际变量名是e
正确姿势：用addEventListener绑定，确保函数签名含event参数，且event.stopPropagation()紧贴逻辑前调用。
label点击区域失效的四大CSS雷区
即使for属性正确、DOM结构合规，label也可能点不动。根本原因常藏在CSS里，尤其在移动端WebView中更敏感。
-
pointer-events: none设在label自身、其任意父级，或被z-index更高的遮罩层盖住，都会让label彻底“失声” -
user-select: none在部分Android WebView中会连带抑制click冒泡；应改用-webkit-user-select: none+-moz-user-select: none，保留标准属性为text -
input被设为display: none或visibility: hidden——浏览器认为它不可交互；可用position: absolute; opacity: 0; width: 1px; height: 1px;替代，确保它仍在可交互DOM流中 -
label是inline元素，无宽高；手指点在文字边缘容易落空——必须加display: inline-block+ 显式padding撑开热区
label里混入button/a等可交互子元素会阻断激活逻辑
把button或a放进label内部，看似能复用样式，实则破坏了label的隐式关联机制。原因很直接：button是独立控件，它会拦截并消耗点击意图，浏览器不再将其视为对input的“激活操作”。
对比来看：div没有默认交互行为，点击它会自然向上冒泡并被label捕获，从而触发input.click()；而button会阻止这一透传逻辑。
- 验证方法：临时加
outline: 1px solid red到label，看是否完整包裹内容；再检查computed styles中pointer-events和display值 - 若需按钮样式，建议用
div+ CSS模拟，或改用显式for关联 + 独立事件绑定 - 避免在
label中混入其他表单控件（如select、另一个input），事件冒泡路径会被干扰，焦点管理混乱
最易被忽略的是composed: true这个布尔值——它不像bubbles那样常被提及，但在Shadow DOM或自定义元素场景下，决定事件能否真正“走出去”。label本身不涉及Shadow DOM，但一旦你把它封装进Web Component，这个细节就会立刻浮出水面。
