viewport 标签必须置于 HTML head 最开头，否则浏览器按默认 980px 初始化布局视口后，后续任何插入或修改均无效；多个同名标签仅第一个生效；content 值须完整包含 width=device-width, initial-scale=1.0，避免写死宽度或禁用缩放；真机验证必不可少，因模拟器无法复现 iOS 键盘、WebKit 渲染等关键行为。
viewport 标签没写在
最开头
浏览器解析 HTML 时， 是最早读取的元信息之一。一旦布局视口按默认 980px 初始化完成，后续任何修改都无效——包括 JS 动态插入、SSR 渲染后补加、甚至放在 后面。
常见翻车点：
-
document.head.appendChild()创建的 viewport 标签，iOS Safari 和多数安卓 WebView 直接忽略 - Vue/React SSR 模板里漏写，客户端 JS 无法“救场”
- 多个
并存，浏览器只取第一个，其余静默丢弃 - 被构建工具（如 Vite 插件）或 CMS 模板自动注入的注释/占位符挤到
后面，导致实际生效位置偏移
content 值被覆盖或写错
用 DevTools → Elements 面板搜索 viewport，再执行 document.querySelector('meta[name="viewport"]')?.content 确认值未被覆盖。常见错误组合：
- 只写
width=device-width：iOS Safari 可能仍 fallback 到 980px 缩放逻辑 - 只写
initial-scale=1.0：安卓部分 WebView 忽略，文字照旧小得看不清 - 写死
width=375或width=414：横屏时直接崩，Pixel 系列或 iPad 上完全错位 - 加了
maximum-scale=1.0或user-scalable=no：系统「更大字体」设置失效，iOS 输入框可能强制放大
真机验证比模拟器更可靠
Chrome DevTools 的设备模拟只是“看起来像”，不模拟 WebKit 渲染内核差异、iOS 键盘弹出时 position: fixed 的行为、或老 Safari 对 flex: 1 + min-height: 100vh 的解析缺陷。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
真正有用的验证方式：
- 本地改完代码，用 HTTP 服务让手机直连访问（
file://页面远程调试不可见） - 打开 Network Throttling → 选 Slow 3G，暴露
srcset没生效、JS 阻塞渲染等问题 - 关掉 Emulate touch events，避免远程调试时元素高亮错位（实际走的是鼠标事件路径）
- iOS 软键盘顶起页面后，
vh单位全乱套，模拟器根本测不出来
检查 layout viewport 宽度是否生效
在真机或模拟器中打开控制台，执行 document.documentElement.clientWidth。以 iPhone 13 为例，应接近 390，不是 980。若仍是 980，说明 viewport 标签完全没生效——大概率是位置错了，或者被其他同名 meta 标签覆盖。
这个值是所有 CSS 布局（包括媒体查询、Flex、Grid、rem 计算）的基准。它错了，后面所有适配逻辑都会失准，但错误现象可能五花八门：按钮点不中、横向滚动条、1px 边框变粗、字体模糊、hover 伪类失效……根源却都指向同一个地方。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
