多端适配实战经验：从响应式布局到动态视口适配的完整方案

谁更灵活？谁更省事？

我做移动端多端适配做了快六年，从最早写 rem + flexible.js 手动算根字体，到后来切 Vue 项目用 postcss-pxtorem 自动转，再到最近两个项目直接上 vw/vh + clamp() 混搭。中间还试过 CSS-in-JS 的响应式方案、Tailwind 的断点系统、甚至自己封装了一套“设备类型 + DPR + 宽度”三重判断的 JS 适配逻辑……最后发现：没有银弹，只有哪个坑我踩得更熟。

今天就只聊最常碰的三种——rem、vw/vh、Tailwind 的响应式断点。不讲原理，不画架构图，就讲你真正在改需求、修 Bug、赶上线时，哪个让你少掉几根头发。

rem：老朋友，但越来越懒得碰

我曾经非常依赖 rem，特别是配合 lib-flexible（阿里那个）或者自己写的动态根字体脚本。它的好处是：所有尺寸都是相对值，缩放统一，文字不会糊，iOS 上动画也顺。

但问题也明摆着：需要额外 JS 控制根字体；不同设备宽度要手动设断点；设计师给的 375px 设计稿，在 iPhone 14 Pro Max 上显示太小，你得加 media query 再调一次 font-size；而且——微信内嵌 WebView 对 document.documentElement.style.fontSize 的设置有延迟或忽略，我踩过三次，每次都是凌晨两点查文档才发现是 UA 判断失效。

核心代码就这几行，但后续维护成本远高于代码本身：

function setRootFontSize() {
  const width = document.documentElement.clientWidth;
  const scale = width / 375;
  document.documentElement.style.fontSize = ${scale * 100}px;
}
window.addEventListener('resize', setRootFontSize);
setRootFontSize();

现在除非是 legacy 项目不能动结构，否则我基本不主动选 rem。它不是不好，是“需要你一直盯着它”，而我现在更想要“写完就忘”的方案。

vw/vh：我目前主力用的，爽是真的爽

我把 vw 当成“自动 rem”。1vw = 1% of viewport width，375px 设计稿下，1rem = 100px ≈ 26.666vw。所以我直接按设计稿像素值除以 375 × 100，换算成 vw 写死。

比如设计师标了 16px 字体 → font-size: calc(16 / 375 * 100vw) → font-size: 4.2666vw；按钮高度 44px → height: 11.733vw。听起来麻烦？不，我直接写个 VS Code snippet，输入 vw16 就自动展开成 calc(16 / 375 * 100vw)，比敲 rem 还快。

关键优势来了：不需要 JS，不依赖 DOM 加载时机，不卡微信内核，CSSOM 渲染即生效。而且现代浏览器支持极好，连 iOS 12+ 都稳稳的。唯一要注意的是：小屏上文字可能过小，所以我会在关键文本加一层 clamp()：

.title {
  font-size: clamp(14px, 4.2666vw, 18px);
}

这行代码的意思是：最小 14px，最大 18px，中间按 vw 缩放。亲测有效，iPhone SE 和 iPad Pro 同时预览，字号过渡自然，不用写一堆 media query。

坑也有一个：vh 在 iOS Safari 中会把地址栏高度算进去，滚动时视口高度突变，导致布局跳动。解决办法？别用 vh 做固定高度容器，改用 min-height: 100dvh（注意是 dvh，不是 vh），iOS 16+ 支持，旧版本 fallback 回 100vh 即可。

Tailwind 的响应式断点：适合组件化强、团队协作的项目

我们上个月接了一个电商 H5，UI 组件库是现成的，用的是 Tailwind。刚开始我本能地想把所有尺寸都改成 vw，结果发现——根本没必要。Tailwind 的 sm:text-base md:text-lg lg:text-xl 写法，在开发效率上碾压手写 media query。

比如一个卡片组件，设计师要求：手机端卡片宽 343px，Pad 端 720px，桌面端 1140px。用原生写法得这样：

.card {
  width: 343px;
}
@media (min-width: 640px) {
  .card { width: 720px; }
}
@media (min-width: 1024px) {
  .card { width: 1140px; }
}

用 Tailwind 就一行：class="w-[343px] sm:w-[720px] lg:w-[1140px]"。更爽的是：这些断点值是全局配置的，改一处，全项目响应。

但它的问题也很实在：断点是离散的，不是连续缩放。比如你有个 banner 图，要求在 375–414px 之间平滑拉伸，Tailwind 给不了，你还得回退到 w-full max-w-[414px] + object-fit 或者干脆上 vw。

另外，Tailwind 的编译产物体积会随 class 使用量增长。我们一个中型 H5，未压缩 CSS 从 80KB 涨到 140KB，CDN 上开了 Brotli 后影响不大，但如果你做的是首屏必须秒开的活动页，就得权衡。

我的选型逻辑

个人项目 or 小型 H5：直接 vw + clamp()。写得快、跑得稳、不用配构建、不依赖框架。我甚至把它抽成了一个 PostCSS 插件，自动把 px 转成 clamp() 包裹的 vw 表达式，一行命令搞定。

中大型 Vue/React 项目，已有组件体系：Tailwind 断点为主，关键模块（如标题、表单输入框）补 vw + clamp()。既保留团队协作友好性，又兜住极端屏幕体验。

rem？除非甲方强制要求兼容 iOS 11 或 Android 4.4 微信，否则我不会再主动加了。它不是技术落后，是维护成本和收益严重失衡——现在连我们测试机里最老的机型都是 iOS 14，真没必要为 0.3% 用户写三套适配逻辑。

顺便提一句：有些同学说“用 CSS container queries 替代 media query”，我试过，目前（2024 年中）Chrome 120+ 支持良好，但 Safari 还在实验阶段，且需要包裹 <div class="size-container"> 才能生效。对于通用 H5，现阶段我还是选择更稳妥的方案。

以上是我的对比总结，有不同看法欢迎评论区交流。比如你还在用 rem 并有一套超顺滑的解决方案？或者你用 @layer utilities + @apply 把 Tailwind 和 vw 混用了？求分享，我真想抄作业。