折叠屏手机是动态显示系统，需实时响应铰链开合；其交互结构依赖screen-spanning媒体查询识别折叠态，结合visualViewport和orientation协同判断悬停态，并以requestAnimationFrame保障DOM更新流畅。
折叠屏手机不是“大号手机”，也不是“双屏平板”——它是一套动态变化的显示系统，交互结构必须随铰链开合实时响应。硬套 min-width 断点或只监听 resize 事件，大概率在 Galaxy Z Fold 或 Pixel Fold 上失效。
别用 resize 监听折叠状态
Chrome 在折叠动画期间会节流 resize，真机上常只触发 1 次，而实际铰链过渡有 3–5 帧。依赖宽度跳变（比如从 673px → 1840px）判断，会把悬停态误判为展开态，或把外屏竖屏当成折叠态。
- 改用
window.matchMedia('(screen-spanning: single-fold-horizontal)')，这是 Chromium 119+ 唯一能稳定识别横屏折叠态的原生媒体查询 - 必须在页面加载初期（
document.readyState === 'interactive'阶段）就执行，否则可能错过初始状态 - 搭配
visualViewport.addEventListener('resize', ...)补充帧级校验，但仅用于防抖，不作为主判断依据
screen-spanning 的真实匹配逻辑
这个媒体特性不是布尔开关，而是分层匹配：同一设备可能同时满足 (screen-spanning: single-fold-horizontal) 和 (min-width: 1800px)，但 CSS 层叠优先级由声明顺序决定，而非“更精确者胜出”。
-
single-fold-horizontal：铰链在上下边，设备横放时两屏并列（如 Z Fold 展开横屏） -
single-fold-vertical：铰链在左右边，设备竖放时两屏上下堆叠（如 Pixel Fold 外屏+内屏竖向叠加） - 未匹配时，浏览器回退到默认单面板布局，无需 JS fallback —— 但要确保基础样式可用
- 桌面 Chrome 或旧版 Android WebView 中该查询返回
not all，此时应降级为orientation+innerWidth组合判断
交互结构必须区分“悬停态”与“展开态”
悬停态（hinge angle ≈ 70°–110°）既不是完全折叠，也不是完全展开，此时用户常将设备斜倚在桌面上，一侧屏幕看内容，另一侧操作控件。若把悬停态当作展开态处理，会导致右侧操作区被遮挡；若当作折叠态，则浪费了可用空间。
立即学习“前端免费学习笔记（深入）”；
- 不要用
display.isFoldable()或deviceInfo.deviceType判断，这些 API 返回的是设备能力，不是当前窗口状态 - 真正可用的是
window.innerWidth+screen.orientation.type+document.visibilityState三者组合：悬停时visibilityState常为prerender，且innerWidth处于中间值（如 1200px 左右），orientation.type可能不稳定切换 - 悬停态下推荐采用“左内容右操作”双栏结构，但右侧栏宽度固定为 320px，不随视口缩放，避免手指误触铰链区域
折叠屏的交互结构适配，本质是状态机管理——铰链角度、窗口尺寸、可见性、方向都在毫秒级变化。没有“一套断点打天下”的方案，最可靠的路径是：用 screen-spanning 抓住确定态，用 visualViewport + orientation 协同兜底悬停态，所有 DOM 更新必须包裹在 requestAnimationFrame 中，否则动画卡顿会直接暴露逻辑漏洞。
