不设 width=device-width 会导致页面以默认 980px 虚拟视口渲染，内容缩小、交互失准；其作用是让浏览器按设备物理宽度（如 375px）布局，缺失时响应式基础全面失效。
不设 width=device-width，页面在多数手机浏览器中会默认以 980px（或类似桌面宽度）渲染，导致内容被强行缩小、文字看不清、点击区域变小——这不是“缩放问题”，是根本没进入移动端适配模式。
为什么浏览器会用 980px 渲染？
移动浏览器（如 Safari、Chrome for Android）内置一个“虚拟视口”（layout viewport），默认宽度约 980px，目的是让未适配移动端的旧网站仍能“勉强显示”。width=device-width 的作用就是告诉浏览器：“别按 980px 渲染，请按设备物理宽度（比如 375px、414px）来布局”。
没有它，max-width: 100%、rem 基准、甚至 touch-action 都可能失效——因为整个布局容器已经错了。
viewport 缺少 width=device-width 的典型表现
- 页面整体被“压缩”成一小条，左右可滑动，文字细小模糊
- 点击按钮时经常点不中，或触发区域偏移
- 使用
window.innerWidth获取到的是 980（而非 375/414），screen.width却是真实设备宽度，二者混淆引发响应式断点错乱 - iOS Safari 中双击放大无效，或放大后无法平滑回弹
只加 width=device-width 还不够？注意这几点
光写 width=device-width 是必要但不充分条件。常见遗漏：
- 漏掉
initial-scale=1：某些安卓 WebView 在横屏后恢复竖屏时，会残留缩放状态，必须显式重置 - 写了
user-scalable=no却没测试辅助功能：iOS VoiceOver 用户可能因此无法缩放阅读，违反可访问性要求 - 动态插入
<meta name="viewport">（如 SPA 路由切换时）无效：该标签必须在中静态存在，JS 后续修改不会触发重排 - 服务端渲染（SSR）场景下，若 HTML 模板里没写，前端 JS 补不上：首屏永远以 980px 开始渲染，即使之后插入也来不及
正确写法与兼容性底线
最简可用且广泛兼容的写法是：
<meta name="viewport" content="width=device-width, initial-scale=1">
不需要 maximum-scale、minimum-scale，除非你明确要禁用用户缩放（通常不推荐）。iOS 10+ 和 Android Chrome 60+ 对这个组合支持稳定；老版 UC、QQ 浏览器也认。
如果项目需兼容 iOS Safari 9 以下（已极少见），避免使用 viewport-fit=cover 或 height=device-height 等扩展属性——它们不仅无用，还可能导致解析失败，降级为无 viewport 的行为。
真正容易被忽略的，是第三方 SDK（比如埋点脚本、广告组件）悄悄注入自己的 viewport 标签，覆盖掉你写的那条。上线前用真机检查 document.querySelector('meta[name="viewport"]') 的实际值，比看代码更可靠。
