双屏移动设备需突破传统响应式设计，通过css容器查询、javascript状态探测及铰链区交互优化实现真实适配。
双屏移动设备（如折叠屏手机、Surface Duo）不是简单地把两个屏幕拼在一起，而是提供可变的显示区域、不同的展开状态和独特的交互上下文。常规响应式设计的 @media (min-width: 768px) 断点在这里会失效——因为设备可能横置单屏、竖置双屏、半展开、或应用跨屏分屏运行。直接套用平板断点，会导致布局错位、手势冲突、内容被裁切。
如何检测双屏设备的真实显示区域而非“伪宽屏”
不能只依赖 window.innerWidth 或 screen.width，它们在折叠状态下常返回合并后的错误值（比如 1800px），实际可用宽度可能只有 400px。必须结合 CSS 容器查询 + JavaScript 状态探测：
- 优先使用
@container（需父容器设container-type: inline-size），它响应的是元素实际渲染宽度，不受设备物理屏幕干扰 - 用
window.matchMedia("(display-mode: standalone)")辅助判断是否为 PWA 模式下的双屏场景 - 检查
navigator.userAgent中是否含Fold、Duo、Surface等关键词，但仅作辅助，不可依赖 - 关键动作：监听
resize和orientationchange，并在回调中调用getBoundingClientRect()获取目标容器真实尺寸
双屏下常见的布局断裂点及修复方式
典型问题不是“太窄”，而是“中间有缝”或“内容被硬切在铰链区”。例如 flex 布局在双屏展开时自动拉伸，导致文字被强行撑开；grid 的 fr 单位在跨屏时无法感知物理缝隙。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 避免用
100vw做全宽容器——它会跨过铰链，造成内容溢出或空白条 - 对跨屏组件（如导航栏、侧边栏），改用
min-inline-size: 320px+max-inline-size: 50%控制单屏内最大占用，防止侵占另一屏 - 铰链区（通常约 16–24px 宽）默认不可交互，CSS 中用
@media (dynamic-range: high)或@supports (aspect-ratio: 1/1)配合 JS 标记该区域为pointer-events: none - 若使用
position: fixed元素（如悬浮按钮），需监听visualViewport变化，手动重定位，否则会在折叠时卡在错误位置
交互逻辑必须区分“单屏操作”与“跨屏协作”
用户在双屏上不是单纯放大界面，而是执行分屏任务流：左屏看图，右屏编辑；上屏选商品，下屏填地址。响应式不能只改样式，要暴露状态供 JS 判断。
- 用
document.visibilityState+document.hasFocus()区分哪一屏当前活跃，暂停非焦点屏的动画或轮播 - 对表单类组件，禁用
autocomplete在双屏模式下自动填充同一字段两次（Chrome 125+ 已修复部分，但仍需校验） - 触摸事件需过滤掉铰链区的误触：通过
TouchEvent.touches[0].clientX与window.innerWidth / 2 ± 20比较，剔除落在中心 ±20px 的点击 - 不要假设双屏 = 更大 viewport：某些设备展开后 height 反而更小（如竖置折叠），应以
Math.min(innerWidth, innerHeight)作为主断点依据
双屏真正的复杂点不在 CSS 写法，而在状态同步——比如用户在左屏滚动到某锚点，右屏是否要联动高亮对应项？这需要明确的通信契约，而不是靠媒体查询自动推导。很多项目卡在“看起来适配了”，实则交互流在双屏下断裂，根源是把双屏当成“大一点的平板”来处理，忽略了它本质是两个独立但协同的显示上下文。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
