Safari伪元素失效因WebKit渲染限制：tr上::after定位失效应改用td；dialog::backdrop不支持backdrop-filter需手动建层；linear-gradient色带需加translateZ(0)和明确color-stop；drop-shadow移出视口消失应避免物理移出。
Safari 里伪元素（::before/::after）不显示、错位或样式失效，不是你写错了，是 WebKit 对某些定位上下文和合成层的处理逻辑更严格——尤其在 tr、dialog::backdrop、linear-gradient 背景等场景下，直接套用 Chrome 写法大概率翻车。
tr 元素上 ::after 在 Safari 中定位失效
当你给 tr 设 position: relative，再用 tr::after 绝对定位画分隔线，Safari 很可能把它“扔”到 table 外面去。这不是 bug，是 WebKit 渲染引擎没把 tr 当作可靠的定位容器。
- 根本原因：
tr的盒模型在表格布局中由渲染引擎隐式管理，position: relative不总触发标准的定位上下文建立 - 别试
will-change: transform或z-index—— 这些对tr无效 - 可靠解法：把伪元素挪到
td上，td行为稳定，且天然支持position: relative - HTML 必须含
td：空<tr class="spacer"><td></td></tr>才能挂载伪元素 - CSS 示例：
tr.spacer td::after { content: ""; position: absolute; top: 0; left: 0; width: 100%; height: 1px; background: #eee; }
dialog::backdrop 上 backdrop-filter 完全不生效
写 dialog::backdrop { backdrop-filter: blur(8px); }，Chrome 可能正常，但 Safari 和 Firefox 直接忽略——控制台里这行样式会被划掉，且无任何报错。
- 规范限制：
backdrop-filter只允许作用于「背景可被用户看到」的元素，而::backdrop是合成层（composited overlay），不参与常规渲染流水线 - Chrome/Edge 120+ 是特例，靠内部 patch 实现，不可依赖
- 必须手动建层：用
<div id="backdrop-blur">覆盖视口，设backdrop-filter+background: rgba(0,0,0,0.3)（透明度不能为 0） - JS 配合：调用
dialog.showModal()前，document.getElementById('backdrop-blur').style.display = 'block' - 层级关键：
#backdrop-blurz-index: 9998，dialog至少z-index: 9999且position: relative
linear-gradient 在 Safari 出现明显色带（banding）
从 #f5f5f5 到 #ffffff 的渐变，在 Safari 滚动或缩放后出现几道清晰灰白分界线，Chrome 看不到——这是 GPU 渲染精度问题，不是颜色选得不对。
立即学习“前端免费学习笔记（深入）”；
- 根因：Safari 默认用 16-bit 渲染通道处理渐变，小色差大跨度时插值失真
- 加
will-change: transform或关-webkit-appearance没用 - 有效做法：用伪元素承载渐变，并强制提升为合成层：
transform: translateZ(0)或backface-visibility: hidden - 必须写
content: ""和inset: 0（别用top/left/width/height） - 显式加
color-stop：比如linear-gradient(to bottom, #f0f0f0 0%, #f8f8f8 50%, #ffffff 100%)，帮 WebKit 明确插值节奏
filter: drop-shadow() 在 iOS Safari 移出视口后消失
用 position: absolute; top: -100px 把元素藏起来，同时加 drop-shadow()，iOS Safari 可能直接不渲染阴影；但用 transform: translateY(-100px) 就只显示一半——方向不同，表现还不一样。
- WebKit 会裁剪超出渲染边界（paint bounds）的
filter效果，尤其是垂直方向移出 - 水平
translateX通常比top更安全，但仍有风险 - 稳妥方案：保持元素在视口内渲染，用
opacity: 0+pointer-events: none隐藏，而非物理移出 - 若必须移出，加
transform: translateZ(0)扩展 paint bounds，有时能救回部分阴影 - 注意：这个行为在 iOS 17–18 仍存在，不是旧版本遗留问题
WebKit 对伪元素的限制不在语法层面，而在渲染流水线的实现细节里——它不拒绝你写 tr::after 或 dialog::backdrop，但可能悄悄绕过你的预期。最省事的优化，往往是从「换宿主」（td 替 tr）、「绕开伪元素」（手动建 backdrop 层）、「强制进合成层」（translateZ(0)）开始，而不是死磕 CSS 规则本身。
