企业官网建设流程全解析

做移动端页面的兄弟应该都有体会：同一套设计稿，要在 iPhone SE 和折叠屏上同时端平，光是字体、间距和边框就能磨掉一下午。最近在整理几个 H5 轻量游戏项目，发现大家页面头部的代码长得几乎一模一样，清一色都是：

<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no">

这个标签写清楚只是开始。真正决定你页面在不同屏幕下不散架、不错位的，其实是 REM、VW 这两个单位，以及它们和 Viewport 的配合方式。这篇文章想把这三者之间的关系彻底掰开揉碎，结合我自己在项目里的实际配置和踩坑记录，给同样被移动端适配折腾过的人一份能直接抄作业的思路。

先交代清楚读者定位：这篇适合手里已经能写出静态页面、但一听到“自适应”“等比缩放”“一像素”就觉得头疼的前端开发，也适合小游戏、低代码页面、H5 活动页的后端同学快速补基础。我会把每个选择背后的为什么说透，而不是只丢结论。

1. 理解 Viewport：移动端适配的第一块基石

1.1 布局视口、视觉视口与理想视口

很多同学天天写<meta name="viewport">，但不知道这行代码到底在干什么。移动端浏览器其实存在三个“视口”概念，弄混了他们，适配就无从谈起。

第一个叫布局视口（layout viewport）。在无 meta 标签约束的情况下，手机浏览器默认会用一个接近 980px 宽度的“虚拟画布”去排版页面，就像把一个桌面网页整个压缩塞进手机屏幕里。你看到的字是缩小的，整个页面的宽度远大于屏幕宽度，要想正常阅读，必须手动缩放或者横竖屏来回切换。这是因为移动浏览器诞生时为了兼容老桌面网站而留下的默认行为。

第二个叫视觉视口（visual viewport），就是用户当前屏幕上看到的那个窗口区域。当你在手机上双指放大页面时，视觉视口会变小，因为你看到的内容范围变少了。

第三个叫理想视口（ideal viewport），它的宽度等于设备的屏幕物理宽度除以设备像素比（devicePixelRatio，后面简称 dpr），对页面开发者来说，就是width=device-width这个值。

<meta name="viewport">标签的作用，就是告诉浏览器：把布局视口设置成理想视口，而不是默认的 980px。这句有点绕的话翻译成人话就是：让页面宽度拉满屏幕，不要在手机上缩成一团。

1.2 meta 参数怎么配才算稳妥

viewport 标签属性里最核心的是width=device-width和initial-scale=1.0。前者把布局视口宽度设为设备宽度，后者把缩放比例卡在 100%，二者同时指定时，浏览器会取两者的较大视口宽度，所以你现在看到的绝大多数项目都是两个一起写。

加上maximum-scale=1.0和user-scalable=no是 H5 游戏、活动页的常见做法，目的是禁止用户双指缩放和误触放大，保护游戏画布和交互按钮的原始布局。我自己在实际项目里对这种写法持保留态度，原因后面讲。还有一类页面会加viewport-fit=cover，这是配套 iPhone 刘海屏的。页面不写这个属性时，Safari 默认按 safe area 布局，在横屏或者全面屏下，左右两侧会出现白边。加上viewport-fit=cover之后，页面才敢真正顶到屏幕边缘，同时配合env(safe-area-inset-*)给按钮和交互元素留出安全距离。

我看过不少项目的 meta 写法是：

<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no" />

如果做的是游戏、答卷、邀请函这类需要锁定视觉比例的页面，这个配置可以接受；但如果是内容阅读型页面，我不建议把user-scalable=no写死。一方面，iOS 10 开始 Safari 主动忽略这个属性，用户仍然可以双击和双指缩放；另一方面，禁掉缩放会伤害视障用户的可访问性。真要防误触，可以用 CSS 的touch-action: manipulation消除双击延迟，没必要牺牲阅读体验。

1.3 Viewport 为什么只是地基

把 Viewport 配好，你能得到一个“宽度正常、不会默认缩小”的移动页面，但页面里的元素尺寸依然是死的：设计稿里标注 100px 的元素，在 375px 宽度的手机上占100/375 ≈ 26.7%的屏宽，在 768px 平板上只占到 13%。这种固定像素布局的问题在于，你没法让元素随着设备一起“生长”。

要让整页比例相对稳定，核心思路是：不再用像素绝对值描述尺寸，而是寻找一个“能跟着设备宽度变化”的度量单位。REM 和 VW 就是两个候选单位，它们解决的问题相似，但侧重点完全不同。

2. REM 方案的原理与核心要素

2.1 为什么是 REM 而不是 EM

CSS 里的 REM 全称是 root em，它的值等于根元素html的font-size。比如你设置html { font-size: 16px }，那页面上width: 2rem就强制解析为 2 × 16px = 32px。万物都跟html走，这就是 REM 的核心逻辑。

EM 则不同，它继承自父元素。父元素字体会变，EM 值就跟着变，很容易出现“嵌套深了数值完全失控”的局面。REM 只认唯一的根节点，全局只要改html一个值，整棵文档树的 REM 尺寸都会跟着变，这种“一改全改”的特性正是做适配最需要的。

另外还要区分 rem 和响应式里常用的%。百分比支持有限，比如padding的百分比是按父元素宽度算的，margin也是，但height的百分比有时不生效，border-radius的百分比又被规范定义为另一种算法。REM 没有这些奇怪限制，凡是能用 px 描述的长度属性，基本都能换成 rem。

2.2 动态根字体：两种主流 JS 套路

REM 要真正服务于适配，前提是根字体大小能跟设备宽度联动。经典方案是：在页面启动时读一次document.documentElement.clientWidth，然后把根字体人为设定为“屏宽的十分之一”或“设计稿 1rem = 100px”等固定换算值。

第一种做法，以 iPhone 6 的 375px 宽为设计基准，直接设置：

(function (doc, win) { var html = doc.documentElement; function setRem() { var width = html.clientWidth; html.style.fontSize = width / 10 + 'px'; } setRem(); win.addEventListener('resize', setRem); })(document, window);

这段代码写的1rem = 375 / 10 = 37.5px。设计稿如果按照 750px 出图，那 1rem 就对应设计稿里的 75px，因为 750 / 10 = 75。所以一套设计稿宽度是 750 时，你在 CSS 里写width: 7.5rem，实际解析宽度正好是设计稿的 750px 屏宽的 1/10 × 7.5 = 屏宽 100%，非常直观。

第二种做法是通过window.matchMedia监听设备宽度变化而不是 resize 事件，顺便在DOMContentLoaded之后再执行一次，防止部分低端 Android 首次加载时字体还没刷上。我通常在代码里直接带上防抖：

function refreshRem() { var width = document.documentElement.getBoundingClientRect().width; var rem = Math.min(width, 768) / 10; document.documentElement.style.fontSize = rem + 'px'; } var timer = null; window.addEventListener('resize', function () { clearTimeout(timer); timer = setTimeout(refreshRem, 200); }); refreshRem();

这里Math.min(width, 768)是限制根字体在平板上不要无脑膨胀，防止页面在 1024px 宽的设备上把所有元素都拉伸得太大。

2.3 从设计稿到 REM 的换算公式

假设你手头是一张 750px 宽的设计稿，屏幕实际宽度 375px，dpr 为 2。底线思路是：设计稿里的 1px 在 CSS 里对应1 / 75 rem，因为 750px 设计稿对应屏宽 375px，而1rem = 37.5px = 375 / 10。所以设计稿里的 100px 宽度，CSS 写作：

100 ÷ 75 = 1.3333rem

如果需要处理的元素比较多，手算太容易出错。我自己的习惯是在 SCSS/Less 里写一个函数：

// 设计稿宽度 750，1rem = 75px @function px2rem($px) { @return $px / 75 * 1rem; } .btn { width: px2rem(200); // 宽度 2.6667rem height: px2rem(96); }

不想用预处理器的，可以用 PostCSS 的postcss-pxtorem插件自动换算。插件配置里有一项rootValue，设成 75，然后声明propList只转换需要的属性，比如：

'postcss-pxtorem': { rootValue: 75, propList: ['*'], selectorBlackList: ['.no-rem'] }

用起来足够省心，但要注意一个坑：如果你在组件库里引入了第三方 UI 框架，有些第三方样式不希望你强行改它的单位。可以让插件在遇到某些类名时跳过，比如.ant-、.van-，或者在第三方样式文件里写/* no-rem */注释让它跳过，千万别全局一把梭。

2.4 REM 方案的软肋

REM 方案最大的问题在于它依赖 JavaScript。只要 JS 没执行、执行晚了、或者执行报错，根字体就是默认 16px，整个页面就变成“设计稿里的 100px 被解析成 100px 固定像素”，在 375px 屏上看着是正常的，在 414px 屏上就开始偏小偏挤。如果你的项目有大量 SSR、首屏要快、用户弱网环境多，就要额外防抖和兜底 CSS：

html { font-size: 37.5px; /* 兜底值，JS 没跑的极端情况 */ }

另外，REM 的“等同缩放”是把字体、间距、图片全部等比拉大。这在游戏、活动页里很爽，但在正文为主的页面里会出问题：小屏手机字 12px 没法看，大屏平板字 28px 又像老年机。所以现代适配策略很少让 REM 孤军奋战，它通常跟 VW 或媒体查询搭配使用。

3. VW 方案：直接用视口宽度说话

3.1 VW / VH 的基本换算逻辑

VW 是 viewport width 的缩写，1vw永远等于当前视口宽度的 1%。这个单位本质上比 REM 更贴近“屏幕”，因为它不依赖 html 根字体，也不用 JavaScript 参与，浏览器自己就能解析。

以 750px 设计稿为例，设计稿里的 1px 对应的 VW 是：

1 / 750 × 100 ≈ 0.13333vw

所以设计稿里 200px 的宽度，CSS 写作：

200 × 0.13333 = 26.6667vw

如果是 375px 的设计稿，那 1px 对应1 / 375 × 100 ≈ 0.2667vw。很多同学在这两个基数之间反复横跳，建议项目定稿之后把设计稿宽度固定在统一值，不要今天 750 明天 375。

VH 是视口高度的 1%，同样很直观。不过它们还有一个兄弟单位是vmin和vmax，在游戏适配里更常用：vmin取vw和vh较小值，vmax取较大值。对于必须保证完整可见的游戏地图、答题卡片，用vmin可以让元素在横竖屏下都保持在屏幕内。

3.2 纯 VW 方案的优势和坑

纯 VW 方案的核心写法是：

html { /* 让 1rem = 1vw * 100 / 7.5，即适配 750 设计稿 */ font-size: 13.33333vw; }

这个数字哪来的？750 设计稿时，100vw = 750px，所以1px = 100/750 vw ≈ 0.13333vw。为了让1rem等于设计稿里的 75px（跟之前 REM 方案对齐），就要让根字体等于75 × 0.13333vw = 10vw。但我们通常想让根字体在 375px 屏上是 37.5px，此时10vw = 37.5px，对应设计稿 75px，换算比 1:2。写起来：

html { font-size: calc(100vw / 7.5); /* 等价于 13.3333vw */ }

这样整个页面继续用 rem 布局，但根字体不再靠 JS 设置，彻底拿掉了脚本依赖。

纯 VW 方案有个非常容易踩的坑：元素宽度一旦超过100vw，页面就会横向滚动。桌面浏览器里滚动条会占宽度，造成100vw包含滚动条宽度，从而出现横向滚动条套娃现象。移动端虽然没有经典滚动条，但在 WebView 里依然可能出现类似问题。解决办法是不要直接写width: 100vw，改写成width: 100%；height: 100vh同理，在移动端遇到地址栏缩放时也不稳定，我会改成100dvh（dynamic viewport height），兼容写法是：先声明height: 100vh再覆盖height: 100dvh。

另外一个坑是字体问题。如果字体也用 VW 等比缩放，375px 屏 12px 的正文，在 414px 屏会变成 13.2px，看着没啥，但在 768px 平板会变成 24px，整个页面像大字报。所以正文大小应当避免纯 vw，最稳的是px+clamp()：

body { font-size: clamp(14px, 2vw, 18px); }

clamp()给出下限、理想值、上限，既保证了中等屏幕的弹性，又避免极端尺寸。

3.3 为什么很多团队转向 VW + REM 组合

纯 REM 有 JS 依赖问题，纯 VW 有字体和溢出问题。实际工程里，两者的协同才是最实用的：用 VW 解决“根字体动态化”，用 REM 解决“元素尺寸弹性化”，用 px 解决“字体、边框的底线”。这样既拿到了 VW 不用 JS 的优势，又保住了 REM 高可读性换算的便利，还能通过clamp()控制极端值。

业内有一段时间特别流行 Flexible 方案（手淘的lib-flexible），后来官方自己也转向了 VW。原因就是 VW 方案更干净，省掉了一段动态脚本，同时更符合现代 CSS 规范。但也不建议你立刻把老项目全部推翻，老项目跑得好好的就别折腾，新项目可以优先 VW+REM。

4. REM / VW / Viewport 三方协同的工程实践

4.1 协同方案一：动态根字体 + REM + viewport

适合页面复杂度高、设计稿严格、需要完全等比缩放的场景，典型如 H5 游戏、大型活动页。整页做成一个大的“画布”，里面所有元素的尺寸、间距、位置都按照设计稿等比换算成 rem。

完整示例骨架如下：

<!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no, viewport-fit=cover"> <title>活动页 / 小游戏</title> <style> html { /* JS 未加载时的兜底 */ font-size: 37.5px; } body { margin: 0; font-size: 16px; background: #0b0f1e; color: #fff; } </style> </head> <body> <div class="game-canvas" id="app">...</div> <script> (function () { var html = document.documentElement; var width = html.clientWidth; // 限制最大适配宽度，防止在 iPad / 横屏上无脑放大 width = Math.min(width, 768); var rem = width / 10; html.style.fontSize = rem + 'px'; })(); </script> </body> </html>

这段代码里有两个点值得展开。第一，viewport-fit=cover只写一次，配合env(safe-area-inset-bottom)确保底部按钮不会被 iPhone 的 Home Indicator 挡住。第二，JS 放 body 末尾执行，避免因脚本执行太早拿不到准确clientWidth。低端 Android 在首帧渲染前执行脚本会导致白屏闪一下，所以我通常会在<html>标签内直接内联执行，或在DOMContentLoaded再刷一次。

这种方案的优点是等比缩放彻底，游戏界面在什么设备上长得都跟设计稿一致；缺点也很明显，正文阅读页这么做会牺牲可读性，所以它不适合博客、新闻、内容社区。

4.2 协同方案二：VW 根字体 + REM 元素 + px 字体

这种方案不需要任何 JavaScript，纯 CSS 搞定，是我目前新项目的默认姿势。

先给 html 设置一个基于 vw 的根字体：

html { font-size: 2.6667vw; /* 375px 屏宽时 = 10px，750 设计稿下 1px = 0.13333vw */ }

这里2.6667vw怎么算的？目标让 1rem = 10px 在 375px 屏宽下成立：10 / 375 × 100 ≈ 2.6667vw。如果设计稿是 750，一个 100px 元素，对应 rem 是100 / 10 = 10rem，非常容易口算。

但上面这个写法在平板、横屏时会失控，所以通常配合clamp()限制根字体的上下限：

html { font-size: clamp(10px, 2.6667vw, 18px); } body { font-size: 14px; /* 不做缩放 */ } @media (min-width: 768px) { html { font-size: 14px; /* 在平板上放弃等比缩放 */ } }

布局套路其实很简单：

.card { width: 8rem; padding: 1.25rem; margin-bottom: 0.75rem; border-radius: 0.5rem; } .title { font-size: 18px; /* 字体固定 px，靠媒体查询调 */ }

我的经验是这样：所有结构性尺寸（宽度、高度、间距、圆角）都用 rem；所有文字字号用 px；需要跟屏幕宽度严格等比但又有上下限的，用 clamp()。这样页面在手机之间弹性适中，在平板上也不会变形到没法看。

4.3 工具链：PostCSS 自动转换与不转换清单

纯手写 rem 对生产力打击太大，建议直接上 PostCSS 插件。VW 方向推荐postcss-px-to-viewport-8-plugin，REM 方向推荐postcss-pxtorem。我这里给一份 VW 方向的可参考配置：

module.exports = { plugins: { 'postcss-px-to-viewport-8-plugin': { viewportWidth: 750, // 设计稿宽度 unitPrecision: 5, // 转换后精度 viewportUnit: 'vw', fontViewportUnit: 'vw', // 字体转换单位（也可以设成 px 禁止转换） selectorBlackList: ['.ignore-vw'], // 命中这些选择器不转换 minPixelValue: 1, // 小于等于 1px 的不转换 mediaQuery: false // 媒体查询中的 px 不转换 } } };

这里特别说明minPixelValue: 1的意义。边框写字1px时，如果转成 vw 会得到小数，在部分安卓机器上渲染出毛边；在 1px 物理线需求场景下更是必须留 px 单独处理。字体我不想转 vw 的时候就配置fontViewportUnit为px或直接在selectorBlackList里排除字体选择器，这样正文可读性有保障。

4.4 配合媒体查询处理特殊节点

适配不是一个单位打天下，媒体查询依然是兜底手段。推荐按业务关键尺寸设置断点，而不是写死“iPhone、iPad”。

.container { width: 100%; max-width: 600px; margin: 0 auto; } @media (max-width: 320px) { .card { padding: 0.5rem; } } @media (min-width: 768px) and (max-width: 1024px) { .container { max-width: 768px; } }

设备像素比 dpr 也值得单独区分。遇到需要适配高清屏的时候，可以结合媒体查询写：

@media (-webkit-min-device-pixel-ratio: 2), (min-resolution: 192dpi) { /* 2 倍屏下的资源替换、边框优化 */ }

比如你要给 2 倍屏切换@2x高清图，用这个 media 条件就比 JS 判断 dpr 更优雅。

5. 适配中常见的坑与排查经验实录

5.1 一像素痛点：物理像素与逻辑像素

移动端最经典的问题就是 CSS 1px 在视网膜屏上看着不止 1px，而是 2px、3px。原因很简单：iPhone 8 的 dpr 是 2，即一个逻辑像素对应两块物理像素。设计师眼里的 1px 细线，用 CSS 的 1px 去表现，实际占用了 2 个物理像素，看起来就是“粗线”。

处理方案我按优先级排列：

1. 对于需要标准 1px 细线的边框，优先用transform: scale(0.5)配合伪元素，把高度压成一半：

.hairline::after { content: ""; position: absolute; left: 0; top: 0; width: 200%; height: 200%; border: 1px solid #ddd; transform-origin: 0 0; transform: scale(0.5); box-sizing: border-box; pointer-events: none; }

2. 对于背景分割线，可以直接用 CSS 渐变模拟：

.divider { height: 1px; background: linear-gradient(180deg, transparent 0%, #eee 50%, transparent 100%); }

3. 某些现代浏览器可以识别border: 0.5px solid #ddd，但兼容性还不够统一，不建议作为唯一方案。

4. 全局缩放 viewport 的思路不推荐，代价太大，会影响布局视口宽度和手势缩放。

5.2 字体大小该用 px 还是 rem？

我上面提过字体不要用 rem/vw 全局等比缩放。这里给一个更具体的例子：某个 H5 项目把正文font-size设成0.4rem，在以 375px 屏宽为基准、根字体 37.5px 时，算出来是 15px，看着正常；但换到 414px 的 iPhone X，根字体变成 41.4px，正文就变成了 16.56px，不明显；等用户拿到一台 768px 的 iPad 横屏，根字体瞬间变成 51.2px，正文直接 20px，这是灾难。

所以我一直用这个组合策略：正文用px固定，再配合媒体查询调整常用字号档位：

body { font-size: 14px; } h1 { font-size: 22px; } @media (min-width: 375px) { body { font-size: 15px; } h1 { font-size: 24px; } } @media (min-width: 414px) { body { font-size: 16px; } h1 { font-size: 26px; } }

如果想在字体上获得视觉节奏：clamp(16px, 1vw + 8px, 20px)这类公式也能用，但注意别直接上100vw / 25，否则在横屏大屏上会失控。

5.3 横屏、刘海屏和安全区的坑

横屏是另外一个经常被忽略的场景。游戏类 H5 一旦方向锁死，横屏适配就成了硬需求。锁方向可以靠@media (orientation: landscape)配合屏幕宽度判断，但不要依赖window.orientation这种老 API，移动端 Safari 已经逐步丢弃。对于必须横屏的游戏，最好在进入游戏前给一个“请横屏”提示层，竖排时显示提示，横屏时自动隐藏：

.rotate-tip { display: none; } @media (orientation: portrait) { .rotate-tip { display: flex; } }

刘海屏安全区是另一个高优先级的坑。主页之前提到viewport-fit=cover之后，底部会被 Home Indicator 遮住。处理办法是加env()间距：

.footer { padding-bottom: 12px; padding-bottom: calc(12px + env(safe-area-inset-bottom, 0px)); }

env()的第二个参数是兜底值，不支持的浏览器会用 0。constant()是旧版 iOS Safari 的写法，前面几个月内还能见到，建议两个都写，把constant()放前面：

padding-bottom: constant(safe-area-inset-bottom); padding-bottom: env(safe-area-inset-bottom);

5.4 动态视口高度与移动端键盘

移动浏览器地址栏的显示/隐藏会导致100vh不可靠：地址栏收起时 100vh 略高，地址栏展开时 100vh 略低，底部内容经常被地址栏遮挡或空白。新单位dvh（dynamic viewport height）就是为解决这个问题的，它实时反映动态视口高度，建议用：

.full-screen { height: 100vh; height: 100dvh; }

在安卓 WebView 中还有软键盘弹起导致的窗口 resize 问题。通常的处理是监听window.visualViewport的resize事件，或者用interactive-widget=resizes-content这个新 meta 属性控制 WebView 行为。这个属性是较新的 H5 适配方式，要真在项目里落地，先确认你的 Android WebView 版本和 iOS 版本的支持情况，别直接全量上线。

5.5 单位换算/工具链出错导致的整体崩盘

PostCSS 转换出现问题的场景也很典型。我遇到过三次项目里所有尺寸都带着 rem，但根字体没设置过，结果浏览器全部按默认 16px 解析，整个页面跟设计稿差了近 2 倍，然后开发组在那边排查了半天“为什么我的 rem 无效”。排查顺序建议是这样：

1. 先查html是否有font-size，是不是被其他样式覆盖了；
2. 再查PostCSS配置，rootValue或viewportWidth是否跟设计稿一致；
3. 看<meta viewport>里的宽度是否是device-width，不是那布局视口宽度就不是屏宽，vw 计算会偏；
4. 最后看浏览器控制台有没有 JavaScript 报错导致动态 rem 脚本没跑起来。

6. 从方案到落地：一套我自用的适配检查清单

文章最后我不打算来一段虚的总结，直接把我现在做移动端适配时会逐条过的 check list 放出来，你照着检查就能少踩很多坑。

1. viewport meta：标准写法width=device-width, initial-scale=1.0，活动页再加maximum-scale=1.0, user-scalable=no，需要刘海屏适配就加viewport-fit=cover；
2. 根字体方案：新项目优先 VW 根字体 + REM 布局；老项目如果已用 Flexible JS 方案，确认脚本有兜底且防抖；
3. 字体大小：用 px + 媒体查询或 clamp()，避免全局等比缩放字体；
4. 1px 边框：统一用伪元素 + transform: scale(0.5) 的封装类；
5. 安全区：所有底部按钮补env(safe-area-inset-bottom)间距；
6. 动态高度：100vh的地方评估是否换100dvh；
7. 横竖屏：需要锁横屏的游戏页面，必须有“请横屏/已检测到横屏”的提示层逻辑；
8. 调试：真机优先，Chrome DevTools 的设备模式仅做辅助，因为 WebView 和浏览器的行为并不完全一致。

我自己在实际项目里的体会是：适配方案没有银弹，但思路可以收敛。REM、VW、Viewport 三者从来都不是互相替代的关系，而是一条链路：Viewport 管浏览器的“视口协议”，VW 提供纯粹的“屏宽比例尺”，REM 则在 VW 之上做了一层方便换算和统一调配的“根字体抽象”。把这条逻辑理顺了，不管设计稿出 375 还是 750，不管 UI 框架怎么换，你都能在十分钟内配出一套不散架的移动端页面。

最后分享一个小经验：别迷信任何“一行代码解决移动端适配”的方案。所有适配问题最后都会在你没想到的机型上露出马脚。项目里永远留一个“真机回归测试”环节，至少覆盖：iPhone SE 系列、iPhone Pro Max 系列、一台中低端安卓（分辨率别太高）、一台大屏折叠屏或平板。在这些设备上把主要页面都过一遍，你才能安心提交代码。