先画1440再压到390，错的不是压缩是顺序

上线第二天早上，销售在群里连甩三张手机截图。第一张是产品详情页，那张八列的参数表被挤成一条能横向拖动的窄带，可视区里只剩「型号」和「功率」两列，型号名还折成了三行；第二张是首屏，主标题在他那台窄屏手机上排了四行，把下面「获取方案」那个按钮整个顶出了可见范围；第三张是留资表单，七个字段一路滑过三屏才见到提交键。这三个页面在电脑上打开，全都规整得挑不出毛病。

更难解释的是，这个版本刚刚通过评审。会议室那块 27 寸屏上，间距均匀、层级清楚，六个参会的人没有一个提出异议。

翻开源文件，第一张稿是 1440 宽的

把设计文件的版本历史倒着看，链路很清楚。桌面版第一稿在项目第 3 天就出来了，画布宽度 1440，此后两周半改了六轮，间距、字阶、配色全在这块画布上反复推敲。移动端那份稿子出现在交付前第 2 天，只有 375 一档，做法是把桌面稿的三栏拆成一栏、字号统一缩一号、图片等比压窄。它不是重新画的，是翻译出来的。

评审跟着走了同一条路。六轮评审全部投在会议室大屏上，导出的 PDF 按 1440 宽排版，参会者各自坐在一米五到三米外看。移动端稿只在最后一轮结尾滚了不到五分钟，讨论还集中在「按钮颜色要不要跟桌面版保持一致」这种事情上。

而这个站上线一周后的后台数据是：移动端访问占 71%，其中微信内置浏览器又占了六成以上。换句话说，整个网站设计流程里吃掉九成精力的那一版，最终只有不到三成的人真正看到。

但画布宽度只是表层

如果毛病真的只在「起稿画布选错了」，那把 1440 换成 390 就该收工。实际不会。同一个团队在下一个项目里直接从 390 起稿，移动端确实规整了，桌面版却变得空荡荡——内容一栏居中，两侧各留三百多像素的白，业务方看完一句「太寡淡」，又往里补了一圈模块，兜回原点。换画布这个动作本身不产生任何决策，网站设计里那个真正的顺序问题也就还留在原地。

再往下拆一层就看清了。1440 的画布上主内容区通常有 1140 像素，横向能并排塞三到四个模块。市场部要的品牌主张、销售要的客户标识墙、技术部要的参数入口、管理层想挂的宣传片，四样东西横着一排，谁都不用让位，页面看着还挺饱满。整个过程中，没有任何一个环节被迫回答那个问题：这四样里哪一样不该出现在这一页。

换到 390 宽，一栏只能竖着堆，四个模块变成四屏。装不下了才想起要处理，而此时离交付只剩两天，来不及回头跟四个部门重谈优先级，于是折叠面板、Tab 切换、横向滚动条一起上，把内容藏起来。这些手段看上去解决了排版，实际是把选择题原封不动推给了用户。折叠区块的展开率通常只有个位数到两成，横向表格被真正拖到最后一列的比例更低——藏起来和删掉，在数据上的差别没有想象中大。

所以移动端优先在网站设计流程里真正改变的只有一件事：把「哪些内容不进这一页」这个决定，从交付前两天挪到起稿第一天。画布宽度不是目的，它只是逼人在第一天就必须回答这个问题的工具。

从明天起可以直接改的六件事

第一件，把首屏当预算分配。常见手机的逻辑高度在 844 上下，扣掉地址栏和底部安全区，真正可见的首屏大约 720 到 740 像素。这个高度装得下一个主标题、一句副文案、一个按钮，再多就得往下滚。开工前让业务方把「必须出现在首屏」的诉求排成有序列表，说清只取前三项；排不出顺序，这一页就先不动手。

第二件，起稿画布用 390 × 844，同一天把 1440 的框也拉在旁边。先想清楚这一栏内容横过来怎么排——是拆成两栏并列，还是保持居中另配大图。两个尺寸同时起，才不会出现前面那种桌面版寡淡的反弹。中间态交给弹性布局，标注稿只交 390、768、1440 三档；给到五档以上，前端也不会逐档还原。

第三件，断点方向掉个头。基础样式先写移动端，再用 min-width 逐级往上加；不要写完桌面版之后用 max-width 一层层往回砍。后者每加一个断点都是在打补丁，样式覆盖叠上三四层之后，没人说得清某个元素在 768 宽下到底命中的是哪条规则。

第四件，把可点性写成硬指标并在评审时逐项核对：可点区域不小于 44 像素见方，相邻两个可点元素间距不低于 8 像素；正文字号不低于 16 像素——低于这个值，部分手机浏览器在输入框获得焦点时会自动放大整页，用户填完一个字段还得手动缩回去；辅助说明不低于 13 像素。主操作按钮放屏幕下方三分之一，那是单手握持时拇指最舒服的区域，别把提交或关闭塞到右上角。

第五件，表格和图片单列规则。超过三列的表格在移动端一律转成卡片式竖排，或者首列固定、其余横滑，横滑区边缘必须有渐隐遮罩，否则用户会以为已经到头。横向构图的图片在 390 宽下高度只剩 220 上下，主体极容易被裁掉，出图时同时给 3:2 和 4:5 两套裁切框，由页面按屏宽选用。这一步在网站设计交付清单里常被漏掉，结果是同一张图在两种设备上讲的不是一件事。

第六件，改评审方式。稿子提前一天推到每个人手机上，开会前各自先划三分钟，会议室大屏只用来定位正在讨论的位置。上线前真机走查至少覆盖一台窄屏机（375 宽）和一台安卓大屏（412 宽附近），并叠加两个条件：单手操作、网络限速到 3G 档。在浏览器里拖窗口宽度不算数，它测不出手指的遮挡，也测不出真实的等待。

判断这一版是不是翻译件

不必逐条对规范，有个更快的办法：把页面在手机上打开，用手掌遮住上半屏，只看下半部分。如果说不清这一页在讲什么、下一步该点哪里，那这一版仍然是桌面稿压缩出来的产物，规范再多写十条也不解决问题。这条标准同样适用于验收外包交付的网站设计稿，不需要打开任何工具。

还有一个更省事的问题，适合放在每次评审的开场：这一版的第一张稿，是在多宽的画布上画出来的。如果答案是 1440，那接下来讨论的所有移动端毛病，都还只是在处理症状。