折叠屏一展开，768这个断点就开始添乱

验收会开到一半，客户那边有人把手机横过来又摊开，屏幕从一巴掌宽变成一本书大小，页面却没跟着变：主图仍然占满整行，正文字号还是给单手阅读准备的那一档，一行只排得下十七八个字，右边空出一大片。做这个页面的团队当场没接上话——他们测过两款苹果手机、一台安卓大屏、一台平板，唯独没人手里有折叠屏。

这不是漏测一台设备那么简单。内折设备展开后的内屏逻辑宽度落在 673 到 717 之间，比常见的平板断点 768 差了几十像素，正好卡在门槛下方。只要断点表是照着框架默认值抄的，这台设备无论怎么展开，命中的永远是手机那一套样式。要躲开这种事，时间得往前推到项目还没动笔的时候。

立项前两周：先把自己站的视口宽度量出来

断点数字的来源，多数项目是复制粘贴。Bootstrap 给的是 576、768、992、1200、1400，Tailwind 给的是 640、768、1024、1280、1536，两套都能用，但它们描述的是全世界设备的平均分布，不是某一个站访客的分布。一家卖工业设备的企业站，访客七成在工位上用 1920 的外接显示器打开；一家做本地生活服务的，九成流量来自手机端的微信内置浏览器。这两个站套同一张断点表，必然有一头是白做的。

可执行的做法是在改版立项前，先让现网跑满 90 天的视口采集。统计工具默认给的是屏幕分辨率，那个数没用——用户不会都把浏览器最大化，也不见得没开侧边栏。要采的是 window.innerWidth，按 20 像素一个桶写进自定义事件。跑够三个月导出来是一张直方图，波峰一般有三到四个，波峰之间的低谷才是断点该落的位置。断点压在波谷上，意味着几乎没有真实用户的视口卡在样式切换的临界点，这比对着框架默认值猜靠谱得多。

这一步在网页制作的排期里通常只占半天，却决定了后面所有布局讨论的基准。跳过它，设计阶段里「这块放两栏还是三栏」的争论就没有裁判，最后总是谁嗓门大听谁的。

设计阶段：多出来的那一档稿，画的是展开态

拿到直方图之后，网页制作的断点表就不再是五档六档地平铺，而是按真实波谷取三到四档。多数企业站量出来的结果长得差不多：手机档落在 390 附近，平板兼折叠屏展开档落在 660 到 700，笔记本档在 1280 上下，最后加一个超宽上限。

第二档是新增的，也最容易被跳过。673 到 717 这个区间在几年前没有任何设备落进去，所以框架默认断点直接从 640 跨到 768，中间是空的。现在这个区间有了真实用户，就得单独画一张稿。这张稿的要点不是把手机稿等比放大，而是把单栏拆成两栏——用户展开屏幕的动机就是想一次看到更多，如果展开后信息量没变，只是字变大了，他下一秒就会合上。

超宽那一头的处理方向正好相反。3440 宽的带鱼屏上浏览器最大化，主容器若不设上限，正文一行能排到一百二十多个字，眼睛从行尾扫回行首极容易丢行。行长控制在 65 到 75 个字符最舒服，中文大约对应 720 到 840 像素。但不能对所有模块一刀切：正文段落该收窄，卡片墙、数据看板、图片瀑布这类模块反而要放开到 1600 甚至更宽，让多出来的宽度换成更多列，而不是换成两边的空白。同一个页面上这两类模块用不同的容器上限，这是超宽屏适配跟过去写死一个 1200 max-width 最大的区别。

还有一个只在折叠屏上出现的坑：铰链。展开态中间那条物理折痕会压着内容，两栏布局的分栏线正好落在折痕上还算走运，落在某个按钮或一段文字上就很难受。CSS 的环境变量能取到折叠区域的位置；实在不想单独处理，退一步的办法是让两栏间距不小于 24 像素，并且不把关键操作放在页面水平中线附近。

上线前三天：模拟器测不出铰链，也测不出手

稿子落地之后进入验证，网页制作到这一步最常见的失误是全靠浏览器开发者工具拖宽度。拖窗口能验证样式规则有没有写错，但验不出三件事：折叠动作发生瞬间的布局跳变、铰链对内容的遮挡、以及超宽屏上视线扫完一整行的实际负担。

布局跳变尤其得单独测。设备从折叠到展开是一帧之内完成的，视口宽度从 400 直接跳到 700，如果断点切换时元素高度变化剧烈，用户正在读的那段会突然跳走。检查办法很直接：展开后立刻看阅读位置还在不在，丢了就说明断点两侧的内容顺序不一致，通常是某个模块在窄屏被折叠、在宽屏被展开，高度差了好几百像素。稳妥的处理是让同一模块在断点两侧的内容完全一致，只改排列方式。

没有真机也不是没办法。主流手机厂商都提供云真机，按小时计费，折叠屏机型一小时通常十几块到几十块，租两小时足够把首页、列表页、表单页三条关键路径走完。这笔钱在整个网页制作预算里可以忽略，省下的却是上线后被截图挂到群里的概率。超宽屏同理，找一台带鱼屏或把两台显示器拼起来，浏览器拉满，重点看首屏和表单。

验证清单可以很短：展开后阅读位置不丢、铰链不压关键元素、超宽下正文行长不超过 840 像素、每个断点两侧模块数量一致、表单在展开态是否自动变两列。五条逐项过一遍，比写二十页规范管用。

上线后一个月：断点是活的，得跟着数据挪

上线不是终点，因为断点是拿历史数据定的，而设备分布一直在变。上线后继续采视口宽度，满一个月重新出一张直方图，跟立项前那张叠着看：有没有新的波峰冒出来，原来的波谷有没有移位。折叠屏这类新形态的占比，往往一年之内能翻一两倍。

更直接的信号藏在行为数据里。把跳出率和主按钮点击率按视口区间拆开，如果某个区间的跳出率比相邻区间高出五到十个百分点，那一段的布局多半有问题。展开态因为用户基数小，很容易在整体数据里被平均掉，必须单独拆出来看，否则永远发现不了。

调整断点也不需要重做整站。多数情况只是把某一档数值挪二三十像素，或者给某个模块单独加一条容器查询。容器查询按父容器宽度而不是视口宽度决定样式，同一个卡片组件放进侧边栏和放进主区域会自动换排版。在网页制作里用上它之后，很多原本必须靠新增全局断点才能解决的问题，可以在组件内部消化掉，断点表反而更精简。

这一周可以先动手的那件事

如果手上的站还没有视口宽度采集，那所有设计讨论都先放一放。在现网加一段十几行的埋点，把 window.innerWidth 按 20 像素分桶上报，明天就开始攒数据。两周后回头看第一批直方图，多半会发现有些争了很久的布局分歧根本不成立——落在那个宽度区间的用户不到千分之三。

如果采集已经在跑，那就把最近 30 天的数据按 660 到 720 单独筛一次，看看展开态在自己站上究竟有多少人。低于千分之一，这一档可以先不做，把精力挪到超宽屏的容器上限上；超过百分之一，就该在下一轮网页制作迭代里把这张稿补齐，而不是等着验收会上再有人当场把手机摊开。