应使用 aspect-ratio 而非 orientation 判断横屏，因后者仅反映设备自然方向；推荐 @media (min-aspect-ratio: 1.2/1)，配合 clamp()、calc() 及视口单位优化布局，并用 matchMedia 精准检测。
横屏检测该用 orientation 还是 aspect-ratio
直接用 @media (orientation: landscape) 是常见误区。它只判断设备的「自然方向」，不是当前视口宽高比——比如 iPad 竖着放但浏览器窗口被拉宽，orientation 仍返回 portrait，导致样式不触发。
真正可靠的方案是用 @media (min-aspect-ratio: 1/1) 或更精确的 @media (min-aspect-ratio: 16/9)。实际项目中建议从 1.2/1 开始试探，避免误判小尺寸横屏手机。
-
orientation仅适用于原生 App 嵌入 WebView 或明确知道设备物理朝向的场景 -
aspect-ratio是 CSS Media Query Level 4 标准，Chrome 89+、Firefox 83+、Safari 17.4+ 支持；旧版 Safari 需用width > height的 JS 回退 - 不要混用两者，
orientation和aspect-ratio触发逻辑完全不同，叠加反而难调试
如何写一个稳定生效的横屏断点 CSS
别只写 @media (min-aspect-ratio: 1.2/1) 就完事。横屏下常见问题是元素宽度撑满、字体过小、触摸目标变窄——这些要一并修正。
@media (min-aspect-ratio: 1.2/1) {
body {
font-size: clamp(14px, 4vw, 18px);
}
.sidebar {
width: 280px;
flex-shrink: 0;
}
.main-content {
min-width: calc(100vw - 280px);
}
button {
min-height: 44px;
padding: 0 20px;
}
}- 优先用
clamp()控制字号，避免横屏时文字过小看不清 - 固定侧边栏宽度（如
280px）后，主内容区用calc()保证不重叠 - 按钮等可点击区域必须设
min-height，否则横屏缩放后手指点不准
横屏时 rem 单位突然变大或变小怎么办
根源是很多项目用 document.documentElement.style.fontSize = window.innerWidth / 375 * 16 + 'px' 这类脚本动态设置根字体大小，但横屏时 window.innerWidth 变成「高度值」，计算逻辑崩了。
立即学习“前端免费学习笔记（深入）”；
修复方法：统一用 screen.width 和 screen.height 获取设备物理尺寸，或改用 Math.max(window.innerWidth, window.innerHeight) 作为基准。
- 不要依赖
window.innerWidth做响应式字体计算，它随旋转实时变化，且在 iOS Safari 中有延迟 - 如果必须用 JS 控制，监听
resize时加防抖，并用matchMedia('(min-aspect-ratio: 1/1)')判断是否真横屏 - CSS 里尽量少用
rem布局，横屏适配优先用flex、grid和视口单位（vw/vh）
真机横屏测试总失败？这几个坑最常被忽略
iOS Safari 横屏时会强制隐藏地址栏，导致 window.innerHeight 突然变大，但 resize 事件可能不触发；Android Chrome 则可能因虚拟键盘弹出干扰宽高判断。
- 用
window.matchMedia('(min-aspect-ratio: 1.2/1)').matches替代window.innerWidth > window.innerHeight判断 - 横屏样式生效后，检查
overflow-x: hidden是否被意外移除，否则页面会横向滚动 - 部分安卓 WebView 对
aspect-ratio支持不全，上线前务必在目标机型上用远程调试确认getComputedStyle返回的aspect-ratio值
横屏适配真正的难点不在写多少 CSS，而在确认「此刻屏幕到底算不算横屏」——所有后续样式都建立在这个判断之上，错一点，整个布局就偏了。
