仅靠@media (orientation: landscape)无法修复vw/vh横屏错位，因其不改变单位计算逻辑；应禁用100vh/100vw，改用100dvh或--vh变量动态修正，并在媒体查询中安全调整font-size、grid列数等非结构性尺寸。
直接结论：仅靠 @media (orientation: landscape) 重定义 vw/vh 值无法修复横屏错位，因为 vw/vh 本身是浏览器原生单位，不能被媒体查询“覆盖”或“重设”——你写的 width: 100vw 在横屏下依然会按错误的视口宽高计算，媒体查询只控制样式规则是否生效，不干预单位解析逻辑。
为什么 @media (orientation: landscape) 里写 height: 100vh 没用
横屏时 100vh 变成设备物理高度（如 390px），但媒体查询只是“让这条规则生效”，它不改变 vh 的底层计算方式。iOS Safari 在方向切换动画帧中，CSS 已按新方向重绘，而 document.documentElement.clientHeight 还没更新，导致这一帧的 100vh 值严重失真。你加了媒体查询，只是让“错误的高度”在错误的时间被应用得更确定而已。
- 常见误操作：
@media (orientation: landscape) { .full-height { height: 100vh; } }—— 这不会比全局写height: 100vh更稳，反而可能因触发时机延迟造成闪动 - 真正该在媒体查询里调整的是：
font-size、padding、grid-template-columns等非结构性尺寸，它们不依赖视口动态基准 - 若必须撑满可用区域，应改用
min-height: 100dvh（现代浏览器）或height: calc(var(--vh) * 1)（配合 JS 动态注入）
怎样用媒体查询辅助修正 vw/vh 行为
媒体查询不能重定义单位，但可以作为“兜底开关”和“行为隔离层”：在横屏条件下关闭有问题的 vw/vh 用法，启用更可靠的替代方案。
- 禁用危险组合：
@media (orientation: landscape) { .banner { width: 100vw; } }→ 改为width: 100%+ 父容器overflow-x: hidden - 锁定字号波动：
font-size: clamp(14px, 2.5vw, 16px)在横屏下仍会因vw基准变大而膨胀，应在横屏媒体查询中强制降级：@media (orientation: landscape) { body { font-size: clamp(12px, 1.8vw, 14px); } } - 规避 fixed 定位漂移：
position: fixed; bottom: env(safe-area-inset-bottom)必须配合@supports (bottom: env(safe-area-inset-bottom))，不能只靠 orientation 媒体查询 - 首次加载补漏：
window.matchMedia('(orientation: landscape)').matches需在页面加载后立即执行，否则首屏渲染按竖屏规则走，媒体查询来不及介入
哪些值真的能用媒体查询安全重置
真正适合放在 @media (orientation: landscape) 里的，是那些不依赖实时视口尺寸、且变化有明确业务意义的值。
立即学习“前端免费学习笔记（深入）”；
-
grid-template-columns: repeat(3, 1fr)→ 横屏改为repeat(2, 1fr)或1fr（响应可用高度骤减，而非宽度增加） -
padding: 1.5rem 1rem→ 横屏改为padding: 0.75rem 1.5rem（左右空间变大可放宽，上下空间紧张需压缩） -
line-height: 1.6→ 横屏改为line-height: 1.4（避免行高叠加 vh 错误造成文字截断） -
max-width: 800px→ 横屏可保留，但需加@media (max-height: 480px) and (min-width: 640px)双重判断，防折叠屏误判
最易被忽略的一点：横屏错位往往不是某一条 CSS 规则的问题，而是 vh 错误值在多个嵌套层级中被放大——比如父容器用 height: 100vh，子元素又用 height: 50vh，两层误差叠加后偏移量翻倍。与其在媒体查询里逐条修，不如从根上弃用 vh，改用 dvh 或 --vh 变量驱动。
