别用 width: 100vw 或 height: 100vh 控制横屏内容尺寸，它们在横屏下单位含义翻转，是压缩/截断的主因；根本原因是 vh/vw 随屏幕方向互换物理意义，导致宽高计算错位，应改用 aspect-ratio、dvh 和容器约束逻辑实现稳定适配。
直接结论：别用 width: 100vw 或 height: 100vh 控制横屏内容尺寸，它们在横屏下单位含义翻转，是压缩/截断的主因。
为什么横屏后图片或容器被压扁、文字缩成一团？
根本原因是 vh 和 vw 在横屏时物理意义互换：100vh 变成屏幕宽度（约 390px），100vw 变成屏幕高度（约 844px）——但你的样式仍按竖屏逻辑在用，结果就是高度被砍、宽度暴增，弹性布局或绝对定位元素顺势拉伸或塌陷。
- 常见错误现象：
img { width: 100%; height: 100vh; }→ 横屏后图高只剩 390px，被严重压缩 - 字体用
font-size: 4vw→ 横屏后4vw ≈ 4% × 844px ≈ 34px，文字突然巨大且撑破容器 - 固定定位按钮写
bottom: 20px→ 横屏后仍在底部，但视觉上跑到屏幕右侧外
用 aspect-ratio 锁定内容比例，而不是靠宽高值硬撑
长宽比失守的根源，是把比例控制权交给了会随方向变化的视口单位。真正稳定的做法，是让内容载体自己“记住”该有的比例。
-
aspect-ratio必须作用于实际内容元素（如<img alt="移动端横屏模式下CSS如何防止宽屏内容被严重压缩？" >、<div> 带背景图），不能只加在外层容器上<li>设计稿为 750×1334 竖版图，就写 <code>aspect-ratio: 750 / 1334；横屏展示时，浏览器自动按此比例缩放裁切，不依赖vh/vw - 低版本安卓 WebView 不支持
aspect-ratio？补 fallback：height: 0; padding-bottom: calc(1334 / 750 * 100%) - 搭配
object-fit: cover或contain控制缩放方式，不要混用max-width: 100%和width: 100% - 优先用
@media (min-aspect-ratio: 13/9)（≈1.44），覆盖 iPhone 15 Pro（19.5:9≈2.17）、主流安卓机横屏比例 - 或退而求其次：
@media (min-width: 600px) and (max-height: 400px)，结合设备真实断点 - 必须确保
<meta name="viewport">含width=device-width，否则所有媒体查询失效 - 横屏专用样式里，只调
font-size、object-fit、padding，坚决不动height/width的单位值 - 给内容包裹层（如
.page-wrapper）设overflow-x: hidden - 同时加
min-width: 100vw; max-width: 100vw，防止内部 flex 项或绝对定位元素意外拉伸容器宽度 - 若遇 iOS WebKit 的
overflow-x: hidden失效 Bug，叠加contain: layout paint强制渲染隔离 - 表格类内容另当别论：用独立
.table-container { overflow-x: auto }，别试图用hidden强压
横屏检测别只信 @media (orientation: landscape)
iOS Safari 在地址栏收起、键盘弹出等场景下会误报 orientation，导致样式错配。更稳的方式是绕过方向判断，直接比宽高关系。
立即学习“前端免费学习笔记（深入）”；
overflow-x: hidden 加在哪才真正生效？
加在 上基本无效，iOS Safari 对 body 的 overflow 处理极不稳定。它必须作用于实际承载内容的块级容器，且该容器要有明确宽高约束。
最易被忽略的一点：横屏适配不是“加一堆媒体查询”，而是放弃对 vh/vw 的路径依赖，把尺寸控制权交给 aspect-ratio、dvh 和容器约束逻辑。一旦开始用 100vh 写高度，你就已经站在了问题起点。
