折叠屏不是 App 的事，Web 页面也会翻车

折叠屏这波新品一出来，很多前端第一反应是：这关我什么事，那不是原生 App 该操心的吗？

真不是。

只要你的页面会在手机浏览器、内嵌 WebView、PWA、企业后台移动端里打开，折叠屏就可能把一个本来正常的布局掰成两半。不是夸张，是字面意义上的两半。

三星美国官网现在已经把 Galaxy Z Fold8 放到购买页里，折叠屏不是什么概念机叙事了，它就是会被用户拿来打开网页的设备。

最容易翻车的不是适配，是误判

我最想提醒的是：别把折叠屏简单理解成「更宽的手机」。

更宽的手机，只是视口变大。折叠屏麻烦的地方在中间那条折痕或铰链。内容如果横跨过去，文字会被打断，按钮会卡在中间，弹窗居中反而会压到最别扭的位置。

web.dev 在「Screen configurations」这篇里把这个问题讲清楚了：屏幕形态还会继续变化，折叠屏会给设计带来新挑战。

这就是标题里说的「Web 页面也会翻车」。

官方已经给了一个口子

好消息是，这件事不是只能靠猜宽度。

Chrome for Developers 在 2025 年 6 月发过一篇文章，Chrome 138 开始支持 Viewport Segments API。它能把被硬件分隔出来的视口区域暴露给前端，CSS 和 JavaScript 都能用。

官方文章里有两个信息值得记住。

一个是，视口片段来自硬件特征，比如折叠屏的折痕或双屏设备的铰链。

另一个是，JavaScript 侧的 segments 现在挂在新加的 window.viewport 上，不再是早期试验里的 window.visualViewport。

这就够我们做一个轻量组件了。

但别急着 All in

这里要泼一盆冷水。

MDN 对 horizontal-viewport-segments 的标记仍然是 Limited availability 和实验技术，意思很直接：不是所有主流浏览器都能用，生产环境得先看兼容表。

所以我的判断是：折叠屏适配应该做，但别上来就重写布局系统。

更稳的方式是把它做成一层渐进增强：支持就切双栏，不支持就回到普通响应式。这样成本低，风险也低。

一个 Vue 组件先兜住

组件的职责不要太大。

它只负责三件事：判断当前是不是多视口、把左右片段尺寸交给页面、在不支持时回退到默认布局。

代码可以长这样：

<script setup>
import { computed, onMounted, ref } from 'vue'

const segments = ref([])

const readSegments = () => {
  const viewport = window.viewport
  segments.value = viewport?.segments ?? []
}

onMounted(() => {
  readSegments()
  window.addEventListener('resize', readSegments)
})

const isFolded = computed(() => segments.value.length > 1)
</script>

<template>
  <section :class="['foldable-shell', { 'is-folded': isFolded }]">
    <slot name="master" />
    <slot name="detail" />
  </section>
</template>

真实项目里还要补 beforeUnmount 移除监听，也要给 window.viewport 补类型声明。这里先看思路：页面不用知道折叠屏细节，只吃一个布局状态。

样式才是关键

如果只写组件，不写样式，适配还是空的。

CSS 侧真正有用的是 horizontal-viewport-segments 和 env(viewport-segment-width 0 0) 这类环境变量。

.foldable-shell {
  display: grid;
  grid-template-columns: 1fr;
  gap: 16px;
}

@media (horizontal-viewport-segments: 2) {
  .foldable-shell {
    grid-template-columns:
      env(viewport-segment-width 0 0)
      env(viewport-segment-width 1 0);
  }
}

这段不是为了炫技，而是把「两块屏幕」当成两块真实区域看待。

左边放列表，右边放详情。左边放表单，右边放预览。左边放聊天列表，右边放当前对话。很多后台和工具类页面，天然适合这个结构。

哪些页面最该先做

不是所有页面都值得为折叠屏单独适配。

营销落地页、文章页、简单表单，继续做好普通响应式就行。折叠屏用户打开它，也只是多一点留白，问题不大。

更应该先动的是这几类：

1. 有主从关系的页面，比如列表和详情。
2. 有实时预览的页面，比如编辑器和结果区。
3. 有地图、图表、视频这类大面积内容的页面。
4. 有居中弹窗、底部抽屉、悬浮按钮的页面。

尤其是第四类，最容易被忽略。普通手机上居中是舒服的，折叠屏上居中可能正好卡在折痕上。

低成本的重点，是别破坏原来的页面

不建议为了折叠屏引入一套新布局。

更好的做法是保留原来的响应式断点，只在支持视口片段时加一层增强。组件负责识别，CSS 负责切换，业务页面只决定两个插槽里放什么。

这样你不是在维护「手机一套、平板一套、折叠屏一套」。

你是在原来的页面上，多塞了一个更懂设备形态的布局开关。

这才是低成本。

现在值得做吗？

如果你做的是内容页，我觉得可以先不动。

如果你做的是工具、后台、SaaS、CRM、低代码编辑器、数据看板，那就值得提前留口子。因为这些产品在大屏手机上打开的概率更高，双栏收益也更明显。

但记住一句话：Viewport Segments API 适合渐进增强，不适合当救命稻草。

基础响应式没做好，折叠屏适配只会把问题放大。

折叠屏不是要前端马上重写页面，它只是提醒我们：移动端已经不再只有一种形状了。

参考

• Chrome for Developers · Support foldable devices with the Viewport Segments API⁽¹⁾
• web.dev · Screen configurations⁽²⁾
• MDN · horizontal-viewport-segments CSS media feature⁽³⁾
• Samsung · Galaxy Z Fold8⁽⁴⁾

引用链接

[1] https://developer.chrome.com/blog/viewport-segments-api-shipped

[2] https://web.dev/learn/design/screen-configurations

[3] https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/At-rules/@media/horizontal-viewport-segments

[4] https://www.samsung.com/us/smartphones/galaxy-z-fold8/buy/

欢迎长按图片添加 poetry 为好友，我会第一时间和你分享前端行业趋势，学习途径，成长内容等等。2026年陪你一起度过！点击领取精心为您整理的前端面试资料

如果觉得这篇内容对你有帮助，我想请你帮我2小忙：