screen-spanning 媒体查询不可靠，不应作为唯一判断依据；它仅在 Chrome 119+/Edge 97+ 支持，Safari/Firefox 不支持，且依赖真实双屏硬件与系统跨屏渲染模式，易因缩放、iframe 或厂商屏蔽而失效。
screen-spanning 媒体查询目前不可靠，别直接用它做主逻辑。它在 Chrome 119+ 和 Edge 97+ 支持，但 Safari、Firefox 完全不支持，且桌面模拟器或旧版 Android WebView 中返回 not all，容易导致样式完全失效。
为什么 screen-spanning 不该作为唯一判断依据
这个媒体特性（如 (screen-spanning: single-fold-vertical)）描述的是「当前 viewport 是否跨过物理铰链渲染」，而非「设备是否处于展开态」。它依赖浏览器合成层对跨屏区域的识别，实际触发条件苛刻：
- 必须是真实双屏硬件（如 Surface Duo）或 Chromium 内核最新折叠屏设备（Z Fold 展开后需系统启用跨屏渲染模式）
- 页面不能被强制缩放或 iframe 嵌套干扰
- 部分厂商系统（如华为 HarmonyOS Webview）会屏蔽该特性以保性能
- 即使匹配成功，
position: sticky、transform等属性在跨屏区可能被截断或卡顿——这不是 bug，是规范明确标注的限制
@media (horizontal-viewport-segments: 2) 更接近物理事实
这是目前最贴近硬件分割状态的 CSS 媒体查询，Chrome/Edge 119+ 支持，专为竖折设备（书本式）展开后双视口并列场景设计：
-
horizontal-viewport-segments: 2表示两个独立水平视口（左屏 + 右屏），document.body.clientWidth返回单侧宽度（约 375–420px），不是总宽 - 它比
min-width或aspect-ratio可靠：不会把横屏平板或大屏手机误判为折叠展开态 - 必须配合
vertical-viewport-segments: 2区分方向——横折设备（盖子式）才走后者 - Grid 布局天然适配：用
grid-template-columns: 1fr 1fr可让内容自然铺满两侧，避免手动计算 hinge 缝隙
JS 必须监听 matchMedia change 事件，且加防抖
仅写 CSS 媒体查询不够。折叠过程中存在半开状态、动画过渡帧、系统延迟上报等，matchMedia 会频繁触发 false positive：
立即学习“前端免费学习笔记（深入）”；
- 直接监听
mediaQueryList.addEventListener('change', handler)，不要只靠 onload 一次性判断 - 给 handler 加 100ms 防抖，否则 Z Fold 展开瞬间可能触发 3–5 次 resize 类似抖动
- 校验
visualViewport.width而非window.innerWidth，前者反映真实可视区域，后者在折叠动画中常滞后 - 降级逻辑要写在 JS 里：
if (!mediaQueryList.matches && screen.width > 700) { /* fallback to width/height combo */ }
env(fold-left) 等环境变量只在 spanning 匹配时生效
env(fold-left)、env(fold-top)、env(fold-height) 这些值不是固定像素，而是运行时由浏览器注入的动态环境变量，前提是当前已命中 screen-spanning 或 horizontal-viewport-segments 查询：
- 未匹配时，
env(fold-left)返回0px或无效值，不能用于布局基准 - 它们适合微调：比如在双屏中间留出 16px 铰链安全区 ——
padding-right: calc(env(fold-left) - 16px) - 千万别用
env()做容器尺寸判断，CSS 计算中它不参与 layout flow，只影响 paint 阶段 - 目前仅 Chromium 实现，Safari/Firefox 会静默忽略，导致 padding 消失而不报错
真正难处理的不是“怎么写 media query”，而是折叠过程中的中间态：半开角度、系统未同步 viewport 尺寸、WebView 初始化时机早于折叠状态上报。这些没法靠一个 CSS 特性兜底，得靠 JS 主动轮询 + CSS 回退组合防御。
