viewport未设width=device-width会导致aspect-ratio媒体查询失效；其与orientation行为不同，前者基于真实宽高比，后者仅比较宽高数值；需注意兼容性、切换瞬态NaN及交界区域歧义。
viewport 未设对，@media (aspect-ratio) 根本不触发
很多开发者一上来就写 @media (aspect-ratio: 16/9)，结果横竖屏切来切去毫无反应——问题大概率出在 <meta name="viewport">。没有 width=device-width，浏览器压根不会按设备真实逻辑宽高比解析视口，aspect-ratio 媒体查询就永远处于“失能”状态。
必须确保 HTML 中有且仅有一条未被 JS 覆盖的 viewport 标签：
<meta name="viewport" content="width=device-width, initial-scale=1.0">
user-scalable=no 或 maximum-scale=1.0 不是必需项，反而可能干扰 Safari 在方向切换时的重绘节奏；固定值如 width=768 更要避免——它会让横屏时的逻辑宽高比计算失效。
@media (aspect-ratio) 和 @media (orientation) 的实际行为差异
aspect-ratio 查询的是视口的宽高比（width / height），而 orientation 只判断宽是否大于高。这意味着：
立即学习“前端免费学习笔记（深入）”；
- 平板横放但系统强制竖屏（如某些教育类 App 或 kiosk 模式），
orientation: landscape会误判，但aspect-ratio > 1仍可准确捕获真实比例 - 折叠屏展开后宽高比接近 2.2:1，
orientation仍报landscape，但aspect-ratio: 22/10可单独匹配做精细化适配 -
aspect-ratio在 Safari 15.4+、Chrome 101+ 才稳定支持；旧版安卓 WebView 基本不识别，需用window.matchMedia+aspect-ratio特性检测兜底
更稳妥的写法是组合使用：
@media (orientation: landscape) and (aspect-ratio > 1.5) { /* 高宽比明显的横屏 */ }用 aspect-ratio 替代 min-width 做断点，为什么更容易踩坑
传统响应式靠 @media (min-width: 768px) 区分平板横竖，但这个值在不同设备上意义混乱：iPad Pro 横屏逻辑宽度是 1024px，Surface Go 却只有 834px。而 aspect-ratio 直接锚定设备物理特性，理论上更可靠。
但实际中容易忽略三点：
- 横竖屏切换瞬间，视口宽高比可能短暂为
NaN（尤其在 iOS Safari 中，旋转动画未完成前）——此时媒体查询会跳过匹配，建议加一层@media (orientation: landscape), (aspect-ratio > 1)宽松 fallback - CSS 里用
aspect-ratio: 16/9是设置元素自身比例，和媒体查询里的(aspect-ratio: 16/9)完全无关，别混淆 - 部分安卓定制 ROM（如华为 EMUI 12）在锁屏旋转后，
matchMedia('(aspect-ratio)')返回matches: false，即使视口已变，得监听window.resize后延时 100ms 再查一次
JavaScript 主动查 aspect-ratio 状态时的兼容写法
不能只依赖 CSS 媒体查询，尤其要做 DOM 动态调整（比如横屏加载高清图、隐藏侧边栏）时，必须用 JS 主动判断。
正确姿势是：
const mql = window.matchMedia('(aspect-ratio: 16/9), (aspect-ratio: 21/9), (aspect-ratio > 1.8)');<br>function handleAspectChange(e) {<br> if (e.matches) {<br> document.body.classList.add('wide-screen');<br> } else {<br> document.body.classList.remove('wide-screen');<br> }<br>}<br>mql.addEventListener('change', handleAspectChange);<br>// 首次加载必须手动调用<br>handleAspectChange(mql);注意：matchMedia 不支持 aspect-ratio 的老浏览器（如 Chrome < 101），要用 try/catch + 回退到 window.innerWidth / window.innerHeight 计算，但后者在 pinch-zoom 后不准，慎用。
真正难处理的不是切换逻辑，而是横竖屏交界区域——比如宽高比 1.2~1.4 的设备（多数 10 英寸安卓平板竖屏），aspect-ratio > 1 和 orientation: landscape 判断结果可能相反，这时必须靠业务语义定规则，而不是无脑信媒体查询。
