uni.getEnterOptionsSync()在冷启动时能稳定获取来源参数，如path、query、scene、referral等，但依赖原生层正确透传；热启动时返回空对象，属系统限制，需服务端或本地持久化方案兜底。
uni.getEnterOptionsSync() 在冷启动时能拿到什么
冷启动时，uni.getEnterOptionsSync() 返回的参数和 App.onLaunch 的回调完全一致，是当前启动最权威的“来源凭证”。它能稳定捕获从 H5（通过 Universal Links / App Links）、小程序跳转、桌面快捷方式、通知栏点击等渠道带进来的 path、query、scene（小程序）、referral（Android）等字段。
但要注意：这个 API 不是“万能钥匙”，它的能力取决于原生层是否成功把 Intent 或启动参数透传给了 JS 层。比如 Android 上如果没正确配置 android:exported="true" 或漏了 intent-filter，或者 iOS 没完成 Apple App Site Association 验证，那即使冷启动，uni.getEnterOptionsSync() 也只会返回空对象。
- 冷启动场景下，务必在
App.vue的onLaunch中第一时间调用，不要延迟或包裹在异步逻辑里 - 返回值中的
query是 URL 查询参数解析后的对象，不是原始字符串；如需原始链接，得靠原生层额外透传（见下一条） - 微信内 H5 跳转 App，必须使用微信开放标签
<wx-open-launch-app></wx-open-launch-app>，且域名已配置可信，否则系统直接拦截，不会触发冷启动流程
热启动时拿不到来源链接？这是设计使然，不是 bug
热启动时 uni.getEnterOptionsSync() 返回空对象，onShow 回调里的 options 也为空——这不是 uni-app 的缺陷，而是 Android/iOS 系统本身就不向已驻留的进程重复传递启动参数。Intent 或 UIApplicationLaunchOptionsKey 只在进程创建时有效，后台唤醒不重发。
所以别试图“修复”这个行为，而要换思路：把关键参数存在服务端或本地持久化，再由前端主动拉取。
- 推荐方案：H5 跳转前，把业务参数（如订单 ID、活动码）先写入后端临时缓存，并生成一个带时效的 token，跳转链接中只传该 token
- App 热启动后，在
onShow中用 token 主动请求一次服务端，换取完整参数 - 若必须走本地，可在冷启动时用
uni.setStorageSync()存一份，热启动时读取并立即清空，避免脏数据干扰下次冷启
Android 原生层如何补全 query 参数（尤其 referrer）
部分安卓机型或旧版 ROM 在热启动/冷启动时，会把来源 URL 放在 Intent 的 referrer 字段而非标准 data，导致 uni.getEnterOptionsSync() 拿不到完整链接。这时需要原生插件或自定义基座补充透传。
以自定义基座为例，在 MainActivity.java 的 onCreate 中加一段提取逻辑：
String referrer = getIntent().getStringExtra("android.intent.extra.REFERRER");
if (referrer != null && !referrer.isEmpty()) {
// 将 referrer 解析为 query 对象，或直接塞进 launchOptions
JSONObject extra = new JSONObject();
try {
extra.put("referrer", referrer);
// 透传给 JS 层（需配合 plus.runtime.arguments 使用）
} catch (JSONException e) { /* ignore */ }
}- 该字段仅 Android 有，iOS 无对应机制，多端兼容代码需做平台判断
- 获取到的
referrer是完整 URL 字符串，不是 query 对象，JS 层需自行解析（可用new URL()） - 此操作必须在基座构建阶段完成，HBuilderX 默认基座不包含该逻辑，不能靠纯 JS 补救
冷启动路径判断的常见误判点
开发者常把“有没有进入页面”当成“是不是冷启动”的依据，但这是错的。比如用户从桌面图标打开 App，是冷启动；但从通知栏点击一条消息唤醒 App，也可能是冷启动（如果进程已被系统杀死）——两者都走 onLaunch，但来源完全不同。
真正可靠的冷启动标识，是 uni.getEnterOptionsSync() 有非空返回，且 options.scene === undefined（非小程序环境）+ options.path 或 options.query 存在有效值。
- 不要依赖
plus.runtime.isApplicationExist()或plus.runtime.restart()后的状态来反推启动类型，它们不可靠 - 调试时注意：真机测试必须用正式证书打包，开发证书下 Universal Links / App Links 大概率不生效，导致始终拿不到 query
- 某些厂商 ROM（如华为 EMUI）会在冷启动后自动清理 Intent 数据，哪怕刚启动完立刻调用
uni.getEnterOptionsSync()也可能为空，此时只能靠服务端兜底
冷启动来源这件事，从来就不是单靠一个 JS 函数能闭环的。它横跨 H5、服务端、原生配置、系统策略四层，任何一层掉链子，前端看到的就是“空”。别指望一招鲜，得按场景分层处理。
