min-aspect-ratio 是适配超长竖屏最可靠的媒体查询属性，因其直接响应视口宽高比而非设备物理参数；应设为 1/2（0.5）覆盖主流超长屏，避免使用已废弃的 device-aspect-ratio，并配合正确 viewport 设置。
min-aspect-ratio 是解决超长竖屏（比如折叠屏展开态、部分安卓旗舰的 20:9 / 21:9 屏）下内容被过度拉伸或留白过多的关键手段，但它不能单独靠写个固定比值就生效——必须结合视口行为和实际渲染区域判断。
为什么 min-aspect-ratio 比 height 或 orientation 更适合超长屏适配
移动端横竖屏切换用 orientation 很直观，但超长竖屏（如 21:9）在 orientation: portrait 下宽高比远小于常规 9:16（即 width/height ≈ 0.476 vs 0.5625），仅靠方向判断会漏掉这批设备。
而 height 媒体查询受地址栏、系统状态栏遮挡影响大，同一台手机在 Chrome 和 WebView 中 max-height 值可能差 80px 以上。min-aspect-ratio 直接反映「可视区域是否特别瘦高」，且响应视口缩放，不依赖物理设备参数。
min-aspect-ratio 的取值怎么算才稳
不要硬套设计稿比例（比如 375×812 → 375/812 ≈ 0.462），要覆盖主流超长屏的下限：
- iPhone 14 Pro Max：390×844 → ≈ 0.462
- Samsung S23 Ultra：384×854 → ≈ 0.449
- Huawei Mate X5 展开态（内屏）：2232×3200 → ≈ 0.697（注意：这是横屏方向，但用户可能竖握使用，此时宽高比倒过来是 ≈ 0.303）
所以稳妥的写法是：
立即学习“前端免费学习笔记（深入）”；
@media screen and (min-aspect-ratio: 1/2) {
/* 宽高比 ≤ 0.5 的设备，即特别瘦高的竖屏 */
.hero { padding-bottom: 25vh; }
.content { line-height: 1.6; }
}这里用 1/2（即 0.5）作为阈值，能覆盖绝大多数超长竖屏，又不会误伤 9:16（0.5625）的常规机型。比值写成 1/2 比 0.5 更可靠——CSS 规范明确要求支持分数形式，且避免小数点精度问题。
容易踩的坑：和 device-aspect-ratio 混用
device-aspect-ratio 及其 min-device-aspect-ratio 已被 Chromium 和 WebKit 标记为废弃（2023 年起），Safari 16.4+、Chrome 115+ 均不再推荐使用。它读的是设备物理屏幕比例，不是当前浏览器窗口的可视区域，会导致：
- 在 PWA 全屏模式下失效（因为去除了系统 UI，可视区域变大）
- 微信内置浏览器中返回错误值（实测某些安卓机上报 16/9，实际渲染是 18.5/9）
- 折叠屏半开态下无法响应（物理屏比例不变，但视口已变）
只用 min-aspect-ratio + max-aspect-ratio 组合，才是面向真实渲染结果的方案。
配合 viewport 设置才能生效
min-aspect-ratio 查询的是视口（viewport）宽高比，如果 <meta name="viewport"> 设置不当，视口会被强制缩放，导致比值失真：
- 错误写法：
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0">——maximum-scale=1.0会锁死双指缩放，但某些安卓 WebView 会因此错误计算视口高度 - 推荐写法：
<meta name="viewport" content="width=device-width, initial-scale=1, user-scalable=no">—— 明确禁用缩放，同时让视口宽度严格等于设备逻辑像素宽 - 额外建议：在 JS 中动态检测并修正
document.documentElement.clientWidth / window.innerHeight，可作为 CSS 媒体查询的 fallback
真正难的不是写对一个媒体查询，而是理解「宽高比」反映的是当前渲染上下文，不是设备说明书上的参数。超长屏适配的本质，是承认视口是动态的、容器是不可信的，只能用最贴近渲染管线的指标来响应。
