Launch Handler API 不直接控制异步启动行为，仅负责可靠传递启动上下文；异步处理逻辑需在 launchQueue.setConsumer 回调中由开发者自行实现，包括延迟导航、预加载、权限校验等。
Launch Handler API 本身不直接控制“异步启动行为”，它只负责在 PWA 被外部触发（如点击链接、打开文件、处理协议）时，将启动上下文（如 URL、文件列表）可靠地传递给应用。真正的异步处理逻辑，需由开发者在 launchQueue.setConsumer 回调中自行组织——重点是延迟导航、预加载资源、校验权限或等待初始化完成，而非让 Launch Handler “变慢”或“排队”。
明确 launchQueue 的执行时机与限制
当系统启动已安装的 PWA（例如用户点击一个 https://myapp.com/share?id=123 链接），浏览器会在页面完全加载前就调用 launchQueue.setConsumer 注册的回调，并把 launchParams（含 targetURL 或 files）传入。这个回调是同步注册、异步触发的，但不能阻塞主文档解析。若你在其中执行耗时同步操作（如未 await 的大型 fetch），会导致白屏或响应卡顿。
- 必须在
<script>标签中尽早注册（建议放在<head>内或使用defer） - 一旦注册，每次外部触发都会调用该 consumer；多次触发会按顺序排队，但不会合并
-
launchParams.targetURL是原始触发链接（可能含 query/hash），不是当前window.location
实现可控的“延迟导航”而非阻塞启动
常见需求如：先检查用户登录状态、加载配置、预取数据，再跳转到目标页。这不是 Launch Handler 的功能，而是你主动控制导航时机：
- 在
setConsumer回调中，暂不调用location.assign()或router.push() - 改用
await等待必要异步准备完成（如 auth check、i18n init、indexedDB 打开） - 准备就绪后，再用
location.replace(launchParams.targetURL)或 SPA 路由器导航 - 若需保留原始 URL 用于后续处理（如 deep link 解析），可暂存
launchParams.targetURL到内存或 sessionStorage
处理多触发场景与竞态问题
用户快速点击多个链接，或同时打开多个文件，可能导致多次 launch 事件进入队列。你需要避免重复初始化或导航冲突：
- 用布尔标记（如
let launched = false）确保核心初始化只执行一次 - 对每个
launchParams单独处理，但共享状态（如 token、theme）应幂等更新 - 若上一次导航尚未完成，新触发的
targetURL可缓存，待当前流程结束再处理，或直接覆盖（取决于业务逻辑） - 注意：
launchQueue不提供取消或中断已有 launch 的 API，需靠应用层协调
验证与降级：确保无 API 时行为一致
并非所有平台/浏览器都支持 launchQueue（如 Safari 完全不支持，旧版 Edge 也不支持）。必须做渐进增强：
- 始终先检测：
if ('launchQueue' in window) { launchQueue.setConsumer(...); } - 未启用时，依赖传统方式捕获入口：监听
pageshow+ 检查document.referrer，或在首页手动解析window.location - 在 manifest.json 中仍需配置
launch_handler（非file_handlers），例如：
{"launch_handler": {"client_mode": "navigate"}}，这是系统识别 PWA 启动行为的基础
