必须将<meta name="viewport">置于<head>最前面、紧邻<meta charset="UTF-8">之后，否则Android WebView和旧版Safari会先按980px渲染再缩放，引发闪屏、字体模糊、点击偏移；width=device-width取的是经DPR换算的CSS逻辑像素宽度（如iPhone 15 Pro为393px），非物理像素，硬写width=375会导致高DPR设备强制缩放、边框发虚、尺寸失真。
必须把 <meta name="viewport"> 放在 <head> 最前面，紧挨 <meta charset="UTF-8"> 后面；否则 Android WebView 和旧版 Safari 会先按 980px 宽度渲染，再缩放，导致闪屏、字体模糊、点击偏移。
为什么 width=device-width 不等于物理像素宽度
它取的是设备的「CSS 逻辑像素宽度」，比如 iPhone 15 Pro 屏幕物理分辨率为 1290×2796，DPR=3，逻辑宽度是 393px；Pixel 8 的 DPR=3.5，逻辑宽度约 412px。如果你用固定 width=375，在 Pixel 8 上浏览器会强制缩放整个页面来“塞进”375px 视口，造成文字发虚、border 粗细不均（如本该 1px 的边框被渲染成 0.35px 或 0.7px）。
常见错误现象：
- iPhone 上字体清晰，安卓机上文字发虚
- 使用
rem布局时，在高 DPR 设备上元素尺寸明显偏小 - CSS 中写了
height: 1px，但实际渲染接近不可见
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 坚持用
width=device-width，不要硬写具体数值（除非做纯 WebView 内嵌页且已锁定设备型号） - 高 DPR 场景下，用
transform: scaleY(0.5)模拟 0.5px 边框，比直接写border: 0.5px solid #000更可靠 - 避免对
font-size做小于 12px 的绝对值设置，iOS Safari 会强制放大
user-scalable=no 会直接违反 WCAG 2.1 可访问性标准
它禁止双指缩放，意味着视力障碍用户无法将页面放大到 400% —— 这是 WCAG 明确要求的最低支持比例。一旦上线，可能触发合规审查或无障碍投诉。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
替代方案更稳妥：
- 保留缩放能力，但用
min-scale=1.0, max-scale=5.0限制范围，防止布局崩坏 - 对图文区域启用
overflow-x: auto，允许横向滑动查看长内容 - 用
word-break: break-word和hyphens: auto防止超长英文单词撑破容器 - 关键操作按钮保持最小触控尺寸 44×44 CSS px，避免缩放后点不准
SSR 或构建工具可能自动删掉 viewport meta 标签
Vite 默认不会删，但某些 SSR 框架（如 Next.js 13+ 的 App Router）会把 <head> 内容交给服务端生成，若你没显式在 layout.tsx 或 head.tsx 里写，它可能被忽略；Webpack 插件如 html-webpack-plugin 若配置了 minify: true，也可能误删未闭合或格式异常的 meta 标签。
检查方法：
- 打开网页，右键「查看页面源代码」，确认原始 HTML 中是否存在该标签（不是 DevTools 里动态注入的）
- 在 Chrome DevTools 的 Network → HTML 请求响应体中搜索
viewport - 用 curl 直接请求 HTML：
curl -s your-site.com | grep viewport
修复动作：
- Next.js：在
app/layout.tsx的<head>内手动添加 - Nuxt：在
app.config.ts的head.meta中声明 - 自建 Webpack：确保
html-webpack-plugin的minify配置里包含removeComments: false
真正容易被忽略的，是「初始渲染时机」——<meta name="viewport"> 必须在第一个 CSS 文件解析前就存在，否则 iOS Safari 会卡住样式计算，等 meta 解析完才重绘，造成白屏延迟。这不是 bug，是 Safari 的渲染机制决定的。
