根本原因是浏览器对原生 radio 的默认渲染与事件响应逻辑不同：Chrome/Firefox 扩展点击区至 label，Safari 仅响应 input 像素级区域，IE/Edge Legacy 甚至忽略 label 包裹作用。
为什么单选框 input[type="radio"] 点击区域在各浏览器里不一致
根本原因不是样式没写对，而是浏览器对原生 input[type="radio"] 的默认渲染和事件响应逻辑不同：Chrome 和 Firefox 会把点击区域扩展到 label 关联范围（尤其当 for 或嵌套正确时），Safari（特别是 iOS WebView）则更保守，常只响应 input 自身的像素级区域；IE/Edge Legacy 甚至会忽略 label 的包裹作用。这导致你点在 label 文字上，在 Chrome 里能选中，在 Safari 里却“点不动”。
必须用 label 包裹 + 显式声明 cursor: pointer
仅靠 for 属性关联不够稳定，尤其在移动端或动态插入节点时。真实项目中应始终采用嵌套方式，并补全交互提示：
-
label必须直接包裹input[type="radio"]和文字，例如：<label><input type="radio" name="x"> 选项A</label> - 给
label加cursor: pointer，让用户明确感知可点击；否则 Safari 下鼠标悬停无反馈，误以为不可操作 - 避免给
input自身设display: none后只靠伪元素模拟——这会切断原生点击穿透链，iOS Safari 尤其容易失效
input[type="radio"] 的尺寸与 transform 会破坏点击区域
很多 UI 库为了统一外观，会对 input[type="radio"] 做 transform: scale(0.8) 或 width: 16px; height: 16px，但这在 Safari 中极易导致点击热区缩小或偏移——它不总跟随视觉缩放更新事件坐标。
- 不要用
transform缩放原生 radio，改用width/height配合vertical-align: middle对齐 - 若必须自定义外观，用
appearance: none后，确保label的点击区域足够大（至少 44×44px 移动端最小触控标准） - 测试时用
element.getBoundingClientRect()查看input的实际width/height，Safari 下常显示为0×0，说明它已脱离可交互流
移动端 Safari 必须加 touch-action: manipulation
iOS Safari 默认对小尺寸点击目标启用延迟（约 300ms），且在某些 zoom 状态下会进一步压缩有效点击区域。不加这个声明，用户快速连点可能被忽略，或点中边缘却无响应。
立即学习“前端免费学习笔记（深入）”；
- 在
label或包裹容器上加：touch-action: manipulation - 配合
user-scalable=no的 viewport 设置效果更稳（但注意可访问性权衡） - 别依赖
-webkit-tap-highlight-color: transparent来“修复”，它只影响高亮色，不解决区域不准
最易被忽略的一点：Safari 对 label 内 input 的 DOM 顺序极其敏感——input 必须在文字前（哪怕只是空格），否则点击文字区域不会触发。这点在 SSR 或模板引擎里容易因换行、注释或动态插值错位。
