initial-scale=1 是 CSS 像素对齐开关，确保视觉视口与布局视口等宽，使 CSS 像素与设备独立像素一一对应；缺失会导致 1px 模糊、媒体查询误判、Canvas 锯齿等问题，且必须与 width=device-width 同行声明。
initial-scale=1 不是“不缩放”，而是 CSS 像素对齐的开关
很多人以为 initial-scale=1 就是让页面“别放大别缩小”，其实它真正的作用是让视觉视口（Visual Viewport）和布局视口（Layout Viewport）在加载瞬间等宽，从而保证 CSS 像素与设备独立像素（DIP）一一对应。漏掉它，哪怕写了 width=device-width，iOS Safari 仍可能以 0.8 缩放加载，导致：
-
1pxborder 实际渲染成模糊的 2~3 物理像素，但视觉粗细失真 -
@media (max-width: 768px)在 393px 宽的 iPhone 上提前触发（因缩放后视口宽度被误判） - Canvas 或 SVG 的
width/height值未按 DPR 校正，出现锯齿或模糊
特别注意：某些旧版 UC WebView 会忽略 initial-scale，但只要 width=device-width 存在，至少能避免默认 980px 渲染；而现代 iOS 和 Chrome for iOS 必须两者共存才稳定。
initial-scale 和 user-scalable 的组合风险极高
单独设 initial-scale=1 是安全的；但一旦搭配 user-scalable=no 或 maximum-scale=1，就会立刻触发可访问性问题和平台兼容性断裂：
-
user-scalable=no在 iOS 16.4+ 已基本失效，但依然会干扰系统级「更大字体」设置，导致视力障碍用户无法放大正文 -
maximum-scale=1在横竖屏切换时可能卡死视口，尤其 PWA 模式下无法恢复 - 双击放大、双指缩放手势在多数安卓浏览器中被静默降级，行为不可预测
WCAG 2.1 明确要求内容支持 200% 缩放 —— 这不是建议，是合规底线。真有强约束场景（如自助终端），必须用 touch-action: pan-x pan-y + JS 控制交互区域，而不是靠 viewport 封锁。
立即学习“前端免费学习笔记（深入）”；
initial-scale=1 在高 DPR 设备上影响 rem 和 vw 计算
initial-scale=1 决定了 CSS 单位如何映射到物理像素。在 iPhone 15 Pro（DPR=3）上，没它时 1rem 可能基于缩放后的视口宽度计算，导致字体忽大忽小；有它时，html { font-size: 100px } 才真正对应 300 物理像素，rem 基准才稳定。
- 设计稿按 375px 宽，
width=device-width+initial-scale=1后，100vw才等于设备逻辑宽度（如 393px），而非 980px - 硬写
width=375会导致 Pixel 8（逻辑宽 ~412px）上文字被压缩，initial-scale无法补偿这种错配 - 若用
vw做响应式字号，initial-scale=1缺失时，font-size: 4vw在横屏下可能突然变小（因视口宽度被错误缩放）
initial-scale=1 必须和 width=device-width 同行声明
不能分开写两次 <meta>，也不能用 JS 动态插入。浏览器解析 HTML 是顺序执行的，viewport 必须在首屏渲染前生效：
- 放在
<meta charset="UTF-8">之后、<title>之前是最稳妥位置 - Vite 默认会移除未闭合或格式异常的
<meta>，Next.js App Router 的head.tsx中若漏写，SSR 输出里就没了 - Webpack 的
html-webpack-plugin开启minify: true时，若 content 值含多余空格或换行，可能被误删
最简且抗错的写法只有一行：<meta name="viewport" content="width=device-width, initial-scale=1">。多一个空格、少一个引号、换行写成两行，都可能让某些 WebView 直接忽略整条声明。
