clip-path 不影响事件捕获，因事件判定基于原始盒模型而非裁剪形状；需用 JS 结合坐标换算与射线法判断点是否在 polygon 内，才能实现仅响应可视区域的交互。
clip-path 本身不影响事件捕获，但裁剪后视觉外的区域仍响应鼠标/触摸事件——这不是 bug，是规范行为。
为什么裁剪后的“空白区”还能点中？
clip-path 只控制「渲染可见区域」，不改变元素的几何边界或 hit-testing 区域。浏览器判定点击是否命中，依据的是元素原始盒模型（content box 或 border box），不是 polygon() 画出的形状。
- 即使
clip-path: polygon(0% 0%, 100% 0%, 100% 30%, 0% 30%)裁出一个窄条，整个原始宽高范围依然可被 pointer 事件触发 - 父容器设了
overflow: hidden也不影响事件穿透——它只裁视觉，不裁事件 - 用
pointer-events: none直接关掉事件，但会连可见部分一起禁用，通常不是想要的效果
让事件只响应裁剪后的可视区域
没有纯 CSS 方案能自动把事件区域收缩到 polygon() 内部，必须结合 JS 做坐标判断。
- 监听
pointerdown或click，用element.getBoundingClientRect()获取元素原始位置，再用event.clientX / clientY换算成相对于元素左上角的坐标 - 对
polygon()顶点做「点在多边形内」判断（常用射线法），仅当坐标落在裁剪路径内才执行业务逻辑 - 如果裁剪形状固定且简单（比如三角形、梯形），可预计算斜率或使用
getPointAtLength()+isPointInPath()（需 canvas 辅助） - 避免在滚动/缩放频繁的场景实时重算——缓存
DOMRect和顶点数组，仅在 resize 后更新
clip-path + pointer-events 的常见误用
有人试图用 pointer-events: none 配合子元素 pointer-events: auto 来“透出”裁剪区，这不可靠：
立即学习“前端免费学习笔记（深入）”；
- 子元素若未显式覆盖整个裁剪区域，边缘点击仍会落到父级透明区，触发默认事件
-
clip-path作用于父元素时，子元素的事件区域仍以其自身盒模型为准，和父级裁剪无关 - 给父级加
isolation: isolate或transform: translateZ(0)不改变事件行为，只影响层叠和裁剪渲染
Safari 和移动端的特殊表现
旧版 Safari（≤16.3）及部分安卓 WebView 对 clip-path 的事件判定更宽松，可能把靠近裁剪边界的点击误判为“外部”；而 Chrome 会严格按原始盒模型处理。
- 调试时别只信 DevTools 的 clip-path 可视化小图标——它只画形状，不标事件热区
- 真机测试必做：iOS Safari、Chrome for Android、Samsung Internet，三者对
clientX/Y → 元素坐标的精度处理有差异 - 若用
path()函数（Chrome 115+ 支持），JS 判断需转为 SVGPathElement +isPointInFill()，Safari 当前不支持该 API
真正难的不是写出 polygon()，而是接受「CSS 裁剪 ≠ 交互裁剪」这个事实——视觉和事件永远分属两个坐标系，强行靠样式对齐只会白忙活。
