必须用 @supports (-webkit-touch-callout: none) 检测并包裹 env(safe-area-inset-top) 样式，因其是 WebKit 稳定指纹；直接写 env() 会导致旧版 Safari 等整条样式失效，加在导航栏自身比 body 更可控，且需注意 scroll-margin-top 叠加和横竖屏切换时 JS 补偿。
直接结论：用 env(safe-area-inset-top) + @supports 检测，给固定头部加 padding-top
不加检测就写 padding-top: env(safe-area-inset-top)，在旧版 Safari、Android WebView 或微信内置浏览器里会整条样式失效，导致顶部内容被刘海硬生生盖住——不是留白不够，是压根没生效。
为什么必须用 @supports (-webkit-touch-callout: none) 而不是检测 env()
因为 @supports (padding-top: env(safe-area-inset-top)) 在 iOS 16+ Safari 中也常返回 false，不可靠；而 -webkit-touch-callout 是 WebKit 内核的稳定指纹，iOS Safari、iPadOS、部分新版 macOS Safari 都支持，且 Android 和桌面端浏览器基本不识别它，能精准圈定目标环境。
- 别写
@supports (env(safe-area-inset-top))—— 语法错误，env()是函数，不能当属性名检测 - fallback 值建议设为
20px或44px（状态栏估算高度），别用0，否则老设备上完全无遮挡缓冲 - 如果你用了 CSS 自定义属性（如
--safe-top），记得在@supports块内重新赋值，外部声明不会自动穿透
加在哪个元素上才真正起作用
加在 body 上看似省事，但容易被后续 position: fixed 的导航栏自身样式覆盖或抵消；更可控的做法是直接作用于导航栏本身：
- 给
.navbar.fixed-top加padding-top: env(safe-area-inset-top)，同时保持height不变（用box-sizing: border-box） - 避免用
top: env(safe-area-inset-top)—— 这只是把导航往下推，不增加内部空间，文字仍可能被截断 - 如果导航栏有背景色或阴影，加
padding-top后视觉更连贯；用margin-top会导致背景断裂
scroll-margin-top 和 env() 叠加时的偏移陷阱
页面有锚点跳转（比如点击目录跳到 #faq），又同时用了 scroll-margin-top 和 env(safe-area-inset-top)，两者会叠加计算。例如 scroll-margin-top: 60px + env(safe-area-inset-top): 44px = 实际偏移 104px，标题被顶得过高。
立即学习“前端免费学习笔记（深入）”；
- 推荐统一写成
scroll-margin-top: calc(1rem + env(safe-area-inset-top))，避免硬编码 - 若用 JS 调
element.scrollIntoView()，别依赖默认行为，显式传入{ block: 'start', inline: 'nearest' }并手动补偿 - 横竖屏切换时，
env(safe-area-inset-top)可能突变（比如从 44px → 0），但 CSS 不会自动重算；需监听resize并触发一次 class 切换强制重绘
真正容易被忽略的是：env() 值只在视口尺寸变化时更新，而 iOS 分屏、多任务、软键盘弹出等场景下，它可能“卡”在旧值上不动——这时候光靠 CSS 不够，得靠 JS 动态读取并 patch。
