折叠屏需手动移动DOM节点而非仅用CSS重排，因媒体查询无法解决语义顺序、屏幕阅读器、SEO、键盘焦点及hinge区域绘制限制等问题。
折叠屏设备上 DOM 结构不能靠 CSS 媒体查询“自动重排”，必须手动移动节点——否则展开态下内容挤在窄列、折叠态下留大片空白，这是最常被忽略的硬伤。
为什么 display: grid 或 flex 无法替代 DOM 移动
CSS 布局仅控制渲染顺序，不改变 DOM 树层级和语义顺序。屏幕阅读器、SEO、键盘焦点流仍按原始 HTML 顺序遍历，且部分折叠屏 WebView（如 Samsung Internet 24+）在 hinge 区域存在绘制限制，浮动或绝对定位元素可能被裁切。
-
grid-template-areas只能重排视觉位置，无法解决语义断裂 -
order属性在跨 hinge 的双屏场景中失效（如 Pixel Fold 内外屏同显时） - 某些 Android WebView 中
getComputedStyle返回的grid-area值不可靠
insertBefore 和 appendChild 的触发时机必须包含初始加载
只监听 resize 事件会导致页面首次渲染时 DOM 位置错误——用户看到的是未适配的折叠态布局，哪怕设备已完全展开。
- 必须在
DOMContentLoaded后立即执行一次判断和移动 - 推荐封装为函数，在
DOMContentLoaded和window.matchMedia(...).addEventListener('change', ...)中调用 - 避免在
resize中高频触发：用requestAnimationFrame节流，或监听visualViewport的resize事件（更精准）
判断展开/折叠态不能只看 window.innerWidth
Pixel Fold、Z Fold 等设备在开合动画过程中 innerWidth 会剧烈抖动（如从 673px → 1840px → 673px），直接比较宽度极易误判。
立即学习“前端免费学习笔记（深入）”；
- 优先用
matchMedia('(min-aspect-ratio: 20/9)')判断超宽屏（展开态），比像素值稳定 - 结合
screen.orientation.type过滤方向：仅当type.includes('landscape') && aspectRatio > 2.0才视为有效展开 - Android WebView 中
screen.orientation可能为null，需 fallback 到visualViewport.width / visualViewport.height
移动 DOM 时要避开 hinge 不可绘制区
铰链物理区域（通常居中 2–4px 宽）在双屏模式下无法正常渲染，强行把关键控件塞进去会导致点击失灵或视觉撕裂。
- 移动前检查目标容器是否跨 hinge：用
getBoundingClientRect()计算元素左右边界，若left hingeCenter + 10，应拆分或避让 - CSS 中用
env(safe-area-inset-left)和env(safe-area-inset-right)辅助预留空间，但注意这些环境变量在 hinge 区域不生效 - 真机测试时务必开启系统“显示触摸区域”调试开关，确认按钮热区未被 hinge 遮挡
DOM 动态调整不是“加个 media query 就完事”，它要求你同时理解浏览器渲染管线、设备硬件限制和辅助技术链路——漏掉任意一环，用户在展开瞬间看到的可能就是错位的按钮、跳失的焦点，或者读屏器念出完全颠倒的操作顺序。
