iOS Safari仅在父容器满足“显式尺寸+独立渲染层+BFC”三条件时才执行overflow:hidden裁剪；缺一不可，常见修复是给父容器加transform:rotate(0deg)强制合成层。
不是 overflow:hidden 写错了，也不是 border-radius 没生效，而是 iOS Safari（及多数 WebKit WebView）在特定条件下压根没执行裁剪——它只在父容器同时满足「显式尺寸 + 独立渲染层 + BFC」时才真正起作用。
overflow:hidden 被静默忽略的三个硬性条件
iOS Safari 不是“失效”，是条件不满足就跳过裁剪逻辑。缺一不可：
-
height或max-height必须是明确像素值或带单位的视口单位（如max-height: 80vh），height: auto或height: 100%会被算作auto，直接忽略overflow: hidden - 父容器必须有独立渲染层（compositing layer），否则裁剪不绑定 GPU 路径——这就是为什么加
transform: rotate(0deg)能“修复” - 需形成块级格式化上下文（BFC），
overflow: hidden本身可触发，但若被祖先的float、position: absolute或 flex 容器干扰，BFC 可能未真正建立
为什么加 transform: rotate(0deg) 就行
这不是魔法，是强制浏览器为该元素创建新合成层，让 overflow: hidden 的裁剪范围严格限定在该图层边界内，和硬件加速路径对齐：
- 必须加在设置了
border-radius和overflow: hidden的**父容器**上，子元素加无效 -
transform: rotate(0deg)兼容性最好（IE9+ 都认），无视觉副作用，Safari 动画场景首选 -
transform: translateZ(0)或will-change: transform效果等价，但部分 Android WebView 中will-change可能被忽略 - 别混用
-webkit-backface-visibility: hidden单独声明——它本身不触发合成层，必须配合translate3d(0,0,0)才稳定（尤其微信 iOS 旧版）
真机上最容易被漏掉的祖先链问题
问题往往不在你写的那个圆角卡片上，而在向上 2–4 层的某个容器里：
立即学习“前端免费学习笔记（深入）”；
- 全局弹窗锁屏时塞在
body上的overflow: hidden，会让所有后代圆角失效 - 第三方 UI 库的
.modal-wrapper、.scroll-container或.page-layout常悄悄加了overflow: hidden - 用
getComputedStyle(el).overflow逐层向上查，直到找到第一个overflow: hidden或overflow: clip的祖先 - 临时删掉疑似祖先的
overflow声明，看圆角是否恢复——这是最快验证方式
video、button、Tooltip 这些特殊场景怎么救
不同元素失效原理不同，不能一招打天下：
-
<video></video>：自身设border-radius无效，必须由**直接父容器**设border-radius+overflow: hidden，且确保容器尺寸 ≥ 实际渲染尺寸（object-fit: cover时特别注意） -
<button></button>：iOS 默认-webkit-appearance: button，会绕过 CSS 渲染层，必须加-webkit-appearance: none才能让border-radius生效 - 带
transform: translateY(-4px)的 Tooltip：子元素位移触发了层叠上下文逃逸，修复点仍在父容器，加transform: rotate(0deg)是最轻量解法 - Safari 悬停动画破框：
transform补丁只能缓解，需换底层机制——用-webkit-mask: radial-gradient(circle at center, #000 0%, #000 12px, transparent 12px)+mask-size: 100% 100%
真正难处理的从来不是单个样式，而是多个渲染机制叠加：祖先 overflow、子元素 transform、父容器尺寸计算、WebKit 合成层策略——它们在桌面端可能相安无事，在 iOS 真机上却会连锁失效。别只盯着 border-radius 值对不对，先确认裁剪逻辑有没有被浏览器真正加载。
