display: "standalone"作用是当用户从主屏幕启动PWA时隐藏地址栏和系统导航栏，实现类原生App体验；它不自动触发独立窗口，需已安装、HTTPS、Service Worker激活及正确start_url等条件共同满足才生效。
manifest.json里display: "standalone"到底起什么作用
它不会让PWA自动以独立窗口打开，而是告诉浏览器：“当用户从主屏幕启动这个PWA时，请隐藏地址栏和系统导航栏，让它看起来像原生App”。实际是否生效，取决于用户是否已将PWA添加到主屏幕，以及浏览器是否支持该模式。
常见误解是设了display: "standalone"就立刻脱离浏览器外壳——其实Chrome、Edge等桌面端默认仍走标签页；只有Android Chrome、iOS Safari（有限支持）在“添加到主屏幕”后才可能触发独立窗口行为。
- 必须配合
"short_name"和"name"字段，否则部分安卓设备拒绝添加到主屏幕 -
display: "minimal-ui"比"standalone"兼容性更好，但UI更接近浏览器 - iOS Safari至今不支持
"standalone"，即使设置了也始终以全屏Safari视图运行
为什么加了standalone还是跳转到浏览器标签页
最常见原因是未满足安装条件：PWA必须通过HTTPS提供，且注册了有效的Service Worker，同时页面至少被访问两次（Chrome要求），才有资格弹出“添加到主屏幕”提示。没被添加，display设置就完全不生效。
另一个关键点：start_url必须可访问且返回200，否则Android Chrome会回退到"browser"模式。
立即学习“前端免费学习笔记（深入）”；
- 检查
start_url是否带查询参数或重定向——应为静态路径如"/"或"/index.html" - 确保
serviceworker.js已正确注册并激活（用DevTools > Application > Service Workers验证） - 桌面Chrome需手动在地址栏点击“安装”图标（或右键菜单），不会自动弹提示
standalone和fullscreen、minimal-ui的区别在哪
三者控制的是不同层级的UI裁剪程度，不是互斥选项，但浏览器按优先级选择最终呈现方式：
-
"fullscreen"：彻底隐藏状态栏、地址栏、系统UI（仅适用于Kiosk或沉浸式场景，需用户授权） -
"standalone"：模拟原生App窗口——保留系统状态栏（时间、信号），但移除浏览器UI（地址栏、标签页、工具栏） -
"minimal-ui"：只隐藏地址栏，保留底部导航栏（Android）或工具栏（桌面），兼容性最好
如果manifest中同时声明多个，浏览器按顺序尝试：fullscreen → standalone → minimal-ui → browser。iOS Safari直接忽略fullscreen和standalone，只认minimal-ui（且效果有限）。
Service Worker没注册成功，standalone就完全失效
manifest.json只是“说明书”，真正接管启动流程的是Service Worker。没有它，浏览器根本不会把页面当作PWA处理，display字段形同虚设。
典型失败场景：SW脚本路径404、scope越界、HTTPS缺失、或者注册代码放在DOMContentLoaded之后导致时机过晚。
- 注册代码必须放在
<script>中且尽早执行，推荐放在<head>末尾 - 检查
navigator.serviceWorker.register()的返回Promise是否reject，错误信息通常是"Failed to register a ServiceWorker" - 确保SW文件响应头包含
Content-Type: application/javascript，否则Chrome会静默失败
standalone不是开关，而是一份对已安装PWA的UI承诺——前提是它真被当成PWA安装了。漏掉Service Worker，等于没发邀请函，再漂亮的manifest也没人来赴约。
