视口配置是移动端适配中最为容易被人忽视的一环，在缺少width=device-width的情况下，移动浏览器会以桌面尺寸来显示整个页面，并且还会整体缩小。虽然从开发者工具来看一切正常，但是到了真实的设备上文字就会变得很小而点不动。2026年的百度移动优先索引已经涵盖了所有的现有网站，如果没有设置视口声明就会被判定为未适配移动端从而受到核心指标降权的影响。基本的做法很简单：width=device-width, initial-scale=1.0；至于user-scalable=no，目前大多数主流规范以及百度移动爬虫都把它当作一种不好的用户体验信号来进行处理，因此允许缩放才是最安全的做法。
REM方案在2026年应该被重新考虑。amfe-flexible已经被标记为废弃，并且不支持iOS 16+的视口缩放策略，继续使用它来计算根字号会导致横竖屏切换或者键盘弹出时出现基准冻结或者异常重置的问题。但是REM并没有死去，它的作用已经从原来的“缩放主干”变成了现在的“字号和间距的统一单位”，即font-size、line-height、padding等属性仍然需要用REM来表示，并且比VW更适合。更好的做法是把根字号交给CSS去控制，例如:root { font-size: clamp(14px, 2.5vw, 16px); }，之后所有的REM值都是根据这个动态根字号来计算的，不需要JavaScript介入。
2026年，VW的兼容性就已经很好了，在iOS和Android 4.4及以上版本上都可以正常使用，不需要用到任何JavaScript就可以实现全屏容器、横幅比例固定以及min-height: 100vh这样的视口级别的效果。但是有两个问题必须要避免：第一，VW必须和viewport meta一起使用，不然的话，在iOS Safari中就会按照980px的布局视口来计算，此时100vw并不等于设备宽度；第二，在双击缩放或者键盘弹出之后，iOS Safari并不会实时更新VW的值，所以window.innerWidth可能会得到错误的结果，并且依靠JavaScript来进行修正反而会使得这个问题更加严重。用纯VW来做字体也是不安全的，在小屏幕的情况下可能会出现小于10px的情况，而被iOS强制调整为12px，造成字体大小突然变化的问题。使用clamp()来限制上下限要比靠运气让VW连续缩放来得可靠得多。
在工程决策上，并不是二选一的问题了，而是分层处理：布局等比缩放交给VW或者postcss-px-to-viewport来处理，并且用selectorBlackList来排除掉一些第三方UI库；字号、内边距以及可访问性相关的属性仍然使用REM或者clamp()；边框、阴影和圆角则继续使用像素值，避免缩放后变粗失真。如果项目还在用REM方案的话，那么至少要把根字号计算的方式从JavaScript转移到CSS中的clamp()里去，从而减少对视口事件的需求。
