根源是父元素设置 border-radius 和 overflow: hidden 后，浏览器按规范以 border box 为裁剪边界处理超出圆角区域的内容，包括绝对定位子元素。
绝对定位元素被父容器圆角裁剪的根源是什么
父元素设置了 border-radius 同时又设置了 overflow: hidden
position: absolute 子元素）直接裁掉——这不是 bug，而是规范行为。关键在于：overflow: hidden 的裁剪边界是父元素的 border box，而 border-radius 定义了这个边界的可视形状。- 裁剪发生在渲染层，不依赖 z-index 或 stacking context 顺序
- 即使子元素
z-index很高、或用transform: translateZ(1px)提升图层，只要父级有overflow: hidden+border-radius，裁剪仍会发生 - Chrome/Firefox/Safari 行为一致，无兼容性差异
绕过裁剪的三种可行方案及适用场景
没有“万能解”，选哪种取决于你能否调整 DOM 结构或样式权责：
- 把绝对定位元素移出父容器 DOM（推荐）：将它作为父容器同级元素存在，用 JS 动态计算位置，或用 CSS
position: fixed+top/left模拟相对定位。适合弹层、下拉、Tooltip 等需要脱离父布局的场景 - 移除父级
overflow: hidden：如果父容器本就不需要内容裁剪（比如只是靠border-radius做视觉圆角），直接删掉它即可。注意检查是否依赖它来隐藏溢出的其他内容（如文字换行、浮动元素） - 用
clip-path替代border-radius：例如clip-path: round(12px)，它不触发overflow: hidden的裁剪逻辑。但注意clip-path在旧版 Safari（<15.4）中对round()支持不全，且无法和box-shadow同时生效（阴影也会被裁）
为什么 transform + will-change 不起作用
常见误区是给绝对定位子元素加 transform: translateZ(0) 或 will-change: transform，以为能创建新图层绕过裁剪。但这是无效的：
-
overflow: hidden的裁剪发生在合成前的渲染阶段，与图层合成无关 -
transform只影响绘制后的位置，不改变该元素是否“属于”被裁剪的 overflow 区域 - 浏览器 DevTools 的 “Layers” 面板里能看到新图层，但裁剪早已在上一帧完成
唯一能打破裁剪链路的方式，是让元素不再处于 overflow: hidden 容器的后代流中——要么 DOM 上移，要么 overflow 移除，要么用 clip-path 这类不触发裁剪的替代方案。
立即学习“前端免费学习笔记（深入）”；
实际调试时最该检查的三处地方
- 看父级 computed style：确认
overflow 是 hidden（不是 auto 或 visible），且 border-radius 值非 0
- 检查父级是否有隐式
overflow: hidden：比如 display: flex + flex-wrap: nowrap + 宽度不足时，某些浏览器会表现类似裁剪（但本质不同，需单独处理）
- 查看元素层级：用 DevTools 的 “Rendering” → “Paint flashing” 或 “Layer borders”，确认绝对定位元素是否真的被渲染在父容器图层内（如果是，说明没逃出裁剪范围）
overflow 是 hidden（不是 auto 或 visible），且 border-radius 值非 0 overflow: hidden：比如 display: flex + flex-wrap: nowrap + 宽度不足时，某些浏览器会表现类似裁剪（但本质不同，需单独处理） 父级圆角 + overflow hidden 的组合非常常见，但它的裁剪效果是“硬性”的。想保住绝对定位内容的完整显示，就得在结构或样式层面主动避开这个裁剪上下文，而不是试图在内部打补丁。
