原生radio无法用CSS伪类实现波纹，须用label包裹并JS动态创建绝对定位span波纹元素，基于offsetLeft/Top计算坐标，仅状态变更时触发，动画仅限transform和opacity，结束后用requestAnimationFrame及时清理。
radio点击时没有默认波纹，:focus-visible也不触发动画
如果你试图给原生的 直接添加点击波纹效果，很可能会碰壁。原因很简单：浏览器压根就没为它设计这类动态视觉反馈。无论是 :active 还是 :focus-visible 伪类，都无法用来启动我们期望的 CSS 过渡动画。你写的那些 transition: all 0.3s 规则，对它来说完全是无效指令——因为单选按钮的视觉切换，本质上是由 checked 这个属性状态驱动的，而不是依赖那些瞬间变化的伪类。
那么，正确的实现路径究竟是什么呢？不妨看看下面这几条经过实践验证的建议：
- 核心思路是事件转移：必须用
标签将包裹起来。这样，用户的点击行为就能从原生的输入框，完美“转移”到我们可以自由定义样式的label上了。 - 隐藏原生控件：将
input设置为position: absolute; opacity: 0; pointer-events: none。这既能确保它不可见，又能防止它意外拦截鼠标事件。 - 自定义波纹容器：在
label内部，额外添加一个如的元素，作为波纹的承载容器。然后，通过 Ja vaScript 监听click事件，动态生成一个绝对定位的来扮演波纹的角色。 - 放弃纯CSS幻想：别试图只用
@keyframes和animation硬生生套上去。波纹的起始点必须是动态的鼠标点击坐标，而这一点，是纯 CSS 动画无法计算和实现的。
用getBoundingClientRect()算不准波纹中心？
计算波纹的扩散中心点，听起来是个简单的减法：用 event.clientX / clientY 减去 label.getBoundingClientRect().left/top 不就好了？但在实际开发中，这个“想当然”的方法经常出问题。一旦 label 元素应用了 transform、设置了 border 或 padding，或者它的父级容器有 overflow: hidden，计算出来的坐标就会出现难以预料的偏移。
要解决这个精度问题，关键得把握以下几个技术细节：
- 使用正确的偏移量：波纹
span的left和top位置，必须基于event.clientX - label.offsetLeft和event.clientY - label.offsetTop来计算。注意，这里用的是offsetLeft/Top，而不是getBoundingClientRect的返回值。 - 定位上下文是关键：务必给
label设置position: relative。否则，offsetLeft/Top的返回值会是 0，导致计算全盘错误。 - 应对复杂布局：如果
label是 Flex 或 Grid 布局的子项，一个更稳妥的做法是，先调用label.getClientRects()[0]获取其第一个矩形信息，再基于此计算偏移量。这通常比直接使用getBoundingClientRect更加可靠。 - 创建时优化性能：波纹
span元素在创建后，应立即通过style.cssText一次性设置好基础样式，例如"position: absolute; border-radius: 50%; pointer-events: none;"。这种做法能有效避免多次重排，提升性能。
波纹缩放+透明度过渡卡顿？
实现波纹动画时，从 transform: scale(0) 放大到 scale(4)，同时配合 opacity 从 0 到 1 的变化，视觉上确实流畅。但是，如果在这个过程中还错误地动画化了 width 或 height 属性，或者没有启用硬件加速，在低端设备上就很容易出现掉帧和卡顿。
要让动画既流畅又高效，下面这几点建议值得反复琢磨：
- 只动画特定属性：严格将动画效果限制在
transform和opacity这两个属性上。浏览器对这两者的合成优化做得最好，能有效利用 GPU 加速。 - 主动提示浏览器：在波纹
span创建时（仅首次即可），为其设置style.willChange = "transform, opacity"。这相当于提前告知浏览器该元素即将发生变化，有助于优化渲染。 - 控制动画时长：过渡时间最好控制在
250ms以内。超过 300ms，人眼就能明显感知到延迟，影响交互的即时感。 - 及时清理DOM：动画结束后，必须手动调用波纹元素的
remove()方法将其从 DOM 中移除。特别是在高频点击的场景下，否则无用节点会持续堆积，拖慢页面性能。 - 在正确时机清理：将移除操作包裹在
requestAnimationFrame回调中执行。这样可以避免在动画进行中间步同步删除元素，从而防止引发页面布局的意外抖动。
radio组里多个选项同时触发波纹？
在处理单选按钮组时，会遇到一个典型的边界问题：当用户点击已经处于选中状态的 radio 时，虽然不会触发 change 事件，但 click 事件仍会照常发生。结果就是，重复点击同一个选项，波纹效果会不断叠加，DOM 里塞满了无用的 span 元素。
要精确控制波纹的触发逻辑，避免这种“幽灵波纹”，需要从事件监听层面进行精细管理：
- 基于状态判断：监听
label的click事件，但在生成波纹前，先判断input.checked === false。也就是说，只在选项从未选中变为选中时，才响应并生成波纹。 - 更稳健的事件绑定：另一个更彻底的方法是，直接使用
input.addEventListener('change', ...)，并在其回调函数里生成波纹。change事件只在checked状态真实发生改变时触发，这从根本上杜绝了重复触发的问题。 - 注意事件冒泡：如果选择
change事件方案，需要特别注意：change事件不会冒泡。因此，必须将事件监听器直接绑定到每个input元素本身，而不能采用事件委托到其label或父容器上的方式。 - 别忘了
name属性：确保同一组内的所有radio都拥有相同的name属性。这是浏览器识别它们为同一组的关键，如果缺失，change事件的互斥逻辑将会混乱。
说到底，实现一个完美的波纹效果，核心目标远不止是“好看”。它的关键在于：能否精准地锚定每一次点击的位置，以及动画结束后能否及时、彻底地完成清理工作。坐标哪怕算错一个像素，波纹就可能飘在按钮之外，显得滑稽而拙劣；而只要漏删一个 span 元素，十次点击之后，页面的 DOM 树上就会多出十个无用的节点，悄无声息地侵蚀着性能。细节，往往决定了交互品质的成败。
