双屏设备识别应优先使用window.matchMedia("(screen-span: single-fold-horizontal)")，fallback方案结合innerWidth、innerHeight和screen.orientation.type；CSS需用env(fold-left)定位折痕，监听visualviewport事件应对键盘弹出，禁用fixed布局与touch-action: pan-y以支持跨屏滚动。
双屏设备识别靠 window.screen 不够用
单纯依赖 window.screen.width 或 screen.availWidth 会把折叠屏误判为普通大屏——比如 Samsung Z Fold 系列展开后 screen.width 可达 2176px，但实际可视区域被铰链分割，中间存在不可用的“折痕区”。window.matchMedia 的 screen-span 媒体特性才是官方推荐方式，但目前仅 Chromium 内核（Chrome/Edge 119+）支持。
- 优先检测
matchMedia("(screen-span: single-fold-horizontal)").matches判断是否为水平折叠双屏 - fallback 方案：结合
window.innerWidth+window.innerHeight+screen.orientation.type综合判断（如展开态宽高比 > 2.0 且 orientation 为landscape-primary） - 避免用
devicePixelRatio做双屏判定——Fold 4 和 Pixel Fold 的 DPR 都是 2.8，但布局逻辑完全不同
@media 断点要避开“折痕陷阱”
双屏设备的媒体查询不能只看总宽度。例如 Z Flip 在翻盖状态下，max-width: 300px 会匹配内屏，但外屏只有 1.9 英寸、分辨率 264×536，实际可用宽度不到 120px（CSS px）。直接套用传统断点会导致按钮过小、文字挤叠。
- 对折叠屏启用独立样式层：
@media (display-mode: standalone) and (min-width: 720px)仅作用于展开态主屏 - 用
env(fold-left)/env(fold-top)CSS 环境变量定位折痕位置（需加-webkit-前缀兼容旧版 Blink） - 慎用
min-device-width——它返回物理像素总宽度，不反映实际可绘制区域
导航结构必须支持跨屏连续滚动
双屏设备用户常将长列表或文档从左屏拖拽到右屏继续浏览，但默认 overflow: hidden 或固定高度容器会截断内容。原生 scroll-snap-type 在跨屏场景下也容易失准。
- 给容器设
overscroll-behavior-x: contain防止横向滚动穿透到父级 - 用
scroll-margin-inline-start: env(fold-right)让 snap 对齐点避开折痕区 - 禁用
touch-action: pan-y——它会阻止跨屏横向拖拽，改用pan-x pan-y并监听touchmove手动修正 scrollLeft
键盘弹出时双屏布局会意外重排
Android 折叠屏在软键盘弹出时，系统可能只收缩当前激活屏的视口高度，导致另一屏内容错位或遮挡。此时 window.visualViewport.height 变化不触发 resize 事件，传统适配逻辑完全失效。
立即学习“前端免费学习笔记（深入）”；
- 监听
visualviewport事件而非resize：visualViewport.addEventListener('resize', handleVpResize) - 键盘弹起后，用
document.activeElement.getBoundingClientRect().bottom动态计算输入框是否被遮挡 - 避免在双屏模式下使用
position: fixed底部操作栏——它会在键盘弹出时卡在错误屏幕
