横屏时定位元素错位的根本原因是top/right等固定像素值在方向切换瞬间被“冻结”，而inset能每次重新绑定当前盒模型，避免错位；需避免混用、做好兼容性兜底，并配合env()与dvh等动态单位确保实时对齐。
横屏时定位元素错位，不是媒体查询没写全，而是 top/right 这类固定像素值在方向切换瞬间已“冻住”，浏览器来不及重算——inset 是目前最稳的解法。
为什么 @media (orientation: landscape) 单独改 top 常常无效
这个媒体查询只响应方向变化信号，但不感知实际渲染状态：iOS Safari 横屏瞬间 100vh 从 844px 骤降到 390px、env(safe-area-inset-top) 突变、地址栏收起延迟触发样式重绘。更麻烦的是，部分安卓 WebView 会滞后数百毫秒才应用规则，元素已错位一帧，再难回滚。
-
right: 16px在横屏下可能把按钮推出屏幕右侧 -
bottom: 24px让弹窗沉入系统返回键下方 -
top: 44px被隐藏的 URL 栏吃掉一半空间
优先用 inset 替代单边偏移
inset 是现代浏览器对 top/right/bottom/left 的语义化封装，它不依赖初始视口尺寸，每次方向切换后都会重新绑定当前盒模型。
-
inset: auto 16px 24px auto等价于竖屏时top: auto; right: 16px; bottom: 24px; left: auto，横屏后自动适配新宽高比 - 避免混用：
inset: 0; left: 50%会导致left覆盖inset的左值，行为不可控 - 兼容性兜底：Chrome 103+、Firefox 102+、Safari 16.4+ 支持；旧版本需 fallback 到四值写法
必须用像素时，靠 env() + calc() 动态算
固定像素值本身没问题，问题出在它没跟着 safe area 或视口变化实时更新。用 env() 抓取运行时安全区，再用 calc() 微调，才能真正对齐视觉锚点。
立即学习“前端免费学习笔记（深入）”；
-
top: calc(env(safe-area-inset-top) + 8px)—— 顶部留白始终贴合状态栏下沿 - 禁用
vh参与定位：top: 5vh在横屏时基准塌缩，定位必然漂移；改用dvh（现代 Safari/Chrome 支持）或rem+ 媒体查询微调 - 父容器加
min-height: 100dvh，防止横屏后高度坍缩导致子元素定位锚点丢失
absolute 元素参考父容器失效的快速验证法
横屏后 .overlay 突然飞到左上角或消失，大概率是它的定位上下文（最近的 position: relative 父容器）在横屏时高度坍缩为 0，或被 transform 隐式创建了新包含块。
- DevTools 中选中该元素，看 Computed 面板里
position是否生效，再逐级检查父元素的position值和实际渲染高度 - 确保父容器明确声明
position: relative，且未被display: contents或transform: scale(0)干扰 - 避免在父容器上同时用
transform和position: relative，这会让它失去作为 absolute 参考点的能力
真正难处理的不是怎么写 CSS，而是横屏切换那一帧的渲染间隙——哪怕所有规则都对，浏览器仍可能先按旧尺寸画一帧，再重绘。这时候 will-change: transform 提前升层、@media 里禁用过渡动画，比死磕像素值更有效。
