必须同时包含 width=device-width、initial-scale=1.0 和 viewport-fit=cover 三项属性，缺一不可；仅靠 viewport meta 标签无法真正全屏，需配合 manifest.json（含 display: "standalone"）及用户“添加到主屏幕”操作才能触发类原生全屏体验。
viewport meta 标签必须包含哪些属性才能触发全屏模式
纯靠 meta name="viewport" 无法真正“全屏”，它只能控制页面缩放与布局视口，但 iOS Safari 和部分 Android 浏览器在用户添加到主屏幕后，会根据特定 viewport 配置启用类原生的全屏体验（即隐藏地址栏、状态栏）。关键不是“全屏”本身，而是让浏览器判定该页面适合以 PWA 或“添加到主屏幕”方式运行。
必须同时满足以下三项：
-
width=device-width：强制视口宽度匹配设备物理宽度 -
initial-scale=1.0：禁止初始缩放，避免触发 Safari 的“双击缩放”逻辑 -
viewport-fit=cover：iOS 11+ 必需，允许内容延伸至刘海/圆角区域（否则即使添加到主屏幕，顶部仍留白）
错误写法：<meta name="viewport" content="width=device-width"> —— 缺少 initial-scale 会导致 iOS 拒绝进入全屏上下文；只写 user-scalable=no 反而可能被 Safari 忽略或降级处理。
为什么加了 viewport-fit=cover 还是显示状态栏
因为 viewport-fit=cover 只是“允许”内容覆盖安全区域，不等于“自动隐藏状态栏”。是否真正隐藏，取决于用户操作路径和平台策略：
立即学习“前端免费学习笔记（深入）”；
- iOS：仅当用户通过 Safari「分享 → 添加到主屏幕」安装为 PWA 后，且页面有合法的
manifest.json（含"display": "standalone"），才会在启动时隐藏状态栏 - Android Chrome：同样依赖
manifest.json+display: standalone，否则即使viewport-fit=cover生效，也只是撑满可视区，状态栏仍在 - 直接在浏览器中打开网页，无论怎么配
meta，状态栏/地址栏都必然存在 —— 这是浏览器安全限制，不可绕过
常见错觉：看到页面“看起来全屏了”，其实是 CSS 用 height: 100vh 强撑，但实际滚动时地址栏收起/展开会触发视口高度跳变，100vh 并非稳定值。
配合 manifest.json 才算完整启用 standalone 模式
单独写 meta 标签只是半截路。真要实现“类 App 全屏启动”，必须提供 manifest.json 文件并正确关联：
- 在 HTML 中声明：
<link rel="manifest" href="/manifest.json"> -
manifest.json至少包含："name"、"short_name"、"start_url"、"display": "standalone"、"background_color"、"theme_color" -
"display": "standalone"是核心，"minimal-ui"已被现代浏览器废弃，"fullscreen"会禁用所有系统 UI（包括返回按钮），实际极少使用
注意：manifest.json 必须通过 HTTPS 提供（localhost 除外），且响应头需含 Content-Type: application/manifest+json，否则 Chrome 会静默忽略。
安卓和 iOS 在全屏行为上的关键差异
同一套 meta + manifest，在两平台表现不同，容易误判问题出在代码上：
- iOS：对
viewport-fit=cover敏感，但对manifest字段校验宽松；即使icons缺失，只要display: standalone存在，添加到主屏幕后就能隐藏状态栏 - Android：更依赖完整 manifest，尤其要求至少一个
icons尺寸 ≥ 192×192，否则 Chrome 不会显示“添加到主屏幕”提示，也不会启用 standalone 模式 - 两者都不支持通过 JS 动态注入
meta或manifest—— 必须在 HTML 初始加载时就存在，否则无效
最常被忽略的一点：iOS 的“添加到主屏幕”入口藏得深（分享弹窗底部向上滑动才出现），很多人没走完这一步就以为配置失败。
