rel="manifest"仅声明manifest.json文件，不直接创建桌面快捷方式；真正起作用的是manifest中display字段（如"standalone"）及用户主动安装行为，需满足HTTPS、必需字段、正确MIME类型等硬性条件。
rel="manifest" 不能用来创建桌面端快捷方式，这是个常见误解。它只用于声明 Web App Manifest 文件，是 PWA（渐进式 Web 应用）的必要配置，但本身不触发快捷方式生成 —— 真正起作用的是 manifest.json 里的 "display": "standalone" 或 "display": "minimal-ui"，以及用户主动“添加到主屏幕”或浏览器自动提示的行为。
为什么 <link rel="manifest"> 单独写没用
这个标签只是告诉浏览器“去加载这个 JSON 文件”，它不携带任何安装逻辑或快捷方式元信息。浏览器读取 manifest 后，是否弹出“添加到主屏幕”提示、是否允许创建桌面图标，取决于：
- manifest.json 是否存在且可访问（HTTP 状态码 200，MIME 类型为
application/manifest+json或application/json） - manifest 中是否包含必需字段：
"name"、"short_name"、"icons"（至少一个 192×192 PNG）、"start_url" - 页面是否通过 HTTPS 提供（本地
localhost除外） - 用户是否曾与页面有交互（如点击事件），否则 Chrome 等浏览器会拒绝触发安装提示
manifest.json 的 display 字段决定桌面行为
真正影响“像原生应用一样打开”的是 display 值，不是 <link> 标签本身：
-
"display": "standalone"：隐藏地址栏和浏览器 UI，启动时像独立应用，桌面快捷方式图标点击后也按此模式打开 -
"display": "minimal-ui"：保留最小返回/刷新按钮，适合轻量级过渡场景 -
"display": "browser"（默认）：完全走浏览器标签页，不会触发安装提示，即使写了rel="manifest"
注意："display": "fullscreen" 虽然更激进，但部分桌面浏览器（如 Edge）可能降级为 standalone，且无法响应系统级窗口控制（如 Alt+Tab 切换）。
立即学习“前端免费学习笔记（深入）”；
桌面快捷方式实际怎么生成
没有自动“打造”这回事。用户必须手动操作，或依赖浏览器策略：
- Chrome / Edge（Windows/macOS）：地址栏右侧出现
+ 添加图标（需满足上述所有条件），点击后生成桌面快捷方式（Windows 下是 .lnk，macOS 下是应用包） - Firefox 不支持桌面快捷方式，只支持“添加到任务栏”（仅 Windows），且不读取
rel="manifest"来触发 - Safari（macOS/iOS）：仅支持 iOS “添加到主屏幕”，不生成 macOS 桌面快捷方式；macOS Safari 完全忽略 manifest 安装逻辑
- Electron / Tauri 等框架才是真·打包成桌面应用，和
rel="manifest"无关
容易被忽略的硬性限制
哪怕代码全对，以下任一条件不满足，快捷方式就出不来：
-
icons数组里没有192x192和512x512尺寸的 PNG（Apple 要求 180×180，但 Chrome 强制检查 192×192） - manifest.json 返回 404 或 Content-Type 不是
application/manifest+json（Nginx/Apache 需显式配置 MIME 类型） - 页面加载后未触发用户手势（比如自动执行
navigator.installPrompt会失败，必须绑定在 button click 上） - Chrome 版本低于 68，或启用了
--disable-features=WebAppInstallIUI启动参数（企业环境常见）
manifest 是入口，不是开关。它准备好了，但最终要不要建快捷方式，浏览器说了算，用户点不点，也得看提示有没有出来 —— 而提示能不能出来，取决于你有没有让页面先“活”起来。
