前几天有个做投放的朋友来找我，说他们在iOS端接Deep Link唤醒的时候遇到一个很头疼的问题：从广告渠道点开链接，App能打开，但用户在落地页里选好的角色、携带的渠道归因参数全都丢了，Unity游戏里的活动页面怎么也跳不过去。排查了半天，最后发现问题出在原生层把参数传给C#的时候，时机不对——Unity的接收脚本还没初始化完成，参数已经先到了，被当成无效消息丢掉了。

这个场景估计很多Unity手游团队都撞上过。Deep Link这个东西，说起来原理并不复杂，无非是把链接里面的参数提取出来，交给游戏里对应的模块去处理。但真要在Unity手游里跑通全流程，从URL Scheme到Universal Links，再到C#层参数投递，中间埋着不少隐藏的坑。这篇文章就把我实际接过的完整链路拆开讲一遍，从XR换季补货到渠道归因、老玩家召回，你可以直接照着抄。

1. 唤醒两种技术路线的核心差异：先选对再动手

在动手写代码之前，先把URL Scheme和Universal Links这两兄弟搞清楚。很多刚接触Deep Link的开发者容易陷入一个误区："既然Universal Links更先进，那就只接Universal Links。"这话在纯iOS应用里有一定道理，但在手游场景下，只接一个其实是给自己埋雷。

1.1 URL Scheme的触发方式与体验瓶颈

URL Scheme本质上就是系统层的一个协议注册。你在Info.plist里声明了你的App能处理什么协议（比如mygame://），那么当Safari或者其他App试图打开这个协议的时候，iOS就会弹出系统弹窗，询问用户是否允许打开你的App。

这个方案最大的优点就是接起来简单，不需要服务器和域名，客户端自己就能搞定。但缺点也很明显：

• 系统会弹一次"打开XX吗？"的确认框，多了一步用户操作，转化率必然会掉一些
• 如果你的App没安装，URL Scheme会直接报错——Safari显示"无法打开网页"，而不是跳转到App Store
• 链接不携带任何域名信息，从安全角度看容易被其他App恶意调用

手游场景下，URL Scheme目前主要的用途是老用户召回和站内跳转，比如玩家在社区里看到一条攻略帖，点击"打开游戏"按钮，通过URL Scheme直接进到对应活动页面。

1.2 Universal Links的能力边界与前置条件

Universal Links是iOS 9之后推出的，它要求开发者具备一个HTTPS的域名，并且在这个域名的根路径下放置一个apple-app-site-association文件（下文统一叫AASA文件）。当用户在Safari里输入或点击一个标准HTTPS链接（比如https://www.mygame.com/event/xxx），iOS会先去检查域名下有没有AASA文件，如果验证通过，就直接拉起你的App，不弹窗。

它的体验显然比URL Scheme好一个档次：

• 无感知唤醒，用户体验丝滑
• 链接本身是标准的HTTPS链接，用户没安装App时点击，仍然可以打开网页端做兜底，而不是报错
• 域名验证机制从系统层面避免了其他App伪装你的协议

但是Universal Links也有让团队头疼的边界条件：

• 必须有一个可通过HTTPS访问的域名，不能只有IP
• AASA文件的放置、更新、CDN缓存问题，会在上线后给你来几次"已经配置了就是唤醒不了"的玄学体验
• iOS 9.2之前还有大小限制（后来放宽到了128KB，基本没影响）
• 部分第三方App内部的WebView对Universal Links支持并不好，Safari里完美，但嵌在某个超级App里可能就失效了

1.3 手游场景下的选型结论

我个人的建议是：两个都接，但分工不同。

广告投放和用户增长场景，主用Universal Links；老玩家召回和App内部跳转，URL Scheme反而更快更稳。两个方案共用同一套参数解析逻辑，原生层拿到URL之后都走同一条路往Unity传。还有一个原因是国内的一些渠道SDK并不支持Universal Links的拉起方式，但URL Scheme兼容性几乎百分百。

2. Unity工程的特殊性：iOS原生代码改在哪，消息怎么和时间赛跑

Unity项目的iOS端原生代码，跟你用Xcode单独建一个App工程的时候差别很大。很多Unity转iOS的开发者第一次打开生成出来的Xcode工程会懵：怎么没有AppDelegate？就算有，改完怎么一重新出包就没了？

这里先把底层的运行机制讲透。

2.1 Unity生成的Xcode工程结构拆解

Unity导出iOS工程之后，你会看到Classes/目录下有一套Unity自带的原生文件，其中最重要的就是UnityAppController。它就是Unity替我们实现的AppDelegate，整个App生命周期都是在它里面管理的。

如果你直接在AppDelegate.mm里写代码，生成出来的工程里可能根本没有这个文件（不同Unity版本结构有差异）。我看过的Unity 2020/2021/2022版本，默认都没有传统的AppDelegate，取而代之的是一个叫UnityAppController的类，App启动流程全部在application:didFinishLaunchingWithOptions:里。

所以正确做法是：写一个UnityAppController的子类，或者直接改UnityAppController.mm。这里我不建议直接改原生文件，原因是每次从Unity编辑器重新出包，Xcode工程都会被覆盖，你改的所有原生代码全没了。正确做法是放到Assets/Plugins/iOS/目录下，让Unity在出包时自动把源码文件拷到Xcode工程里。

2.2 冷启动还是热启动：参数到达时机完全不同

这是整个流程里最关键的变量。Deep Link的唤醒场景可以分成两大类：

• 冷启动：App进程不在，用户点链接，系统拉起App，从application:didFinishLaunchingWithOptions:开始走
• 热启动：App进程已经在后台，用户点链接，走application:openURL:options:或continueUserActivity:回调

冷启动的时候千万不能马上往Unity发消息。为什么？因为Unity引擎都还没起来，你的C#脚本对象压根不存在。你发消息等于对着空气喊话，UnitySendMessage打到一个不存在的GameObject上，直接报错或者静默丢弃。

热启动相对简单，Unity已经在运行了，收到回调之后直接转发就行。

2.3 原生的参数暂存机制

为了解决冷启动时序问题，原生层必须有一个暂存区。我习惯在UnityAppController的子类里维护一个静态字典，把收到的URL参数先存下来，等Unity那边准备就绪之后主动来取。

传给Unity的消息时机，我见过不少人写死在applicationDidBecomeActive里，这样不太合适。因为didBecomeActive在App每次从后台回到前台时都会触发，如果这时候恰好没有暂存数据，也只是空跑一次；但如果你在冷启动后第一次didBecomeActive就发消息，Unity可能还在加载首场景，GameObject可能还不存在，一样会丢。

比较稳的做法是双保险：原生层在UnitySendMessage之前延时一小段时间，同时C#层也做轮询拉取，两边配合确保参数必达。具体怎么配合，后面专门讲。

3. 原生捕获与向Unity投递参数：这层代码决定成败

好，到了真正写代码的部分。这一节我给出一套可以直接用的Objective-C++实现，覆盖URL Scheme和Universal Links两种回调，同时处理暂存、延时和参数格式。

3.1 URL Scheme专用回调

// Assets/Plugins/iOS/DeepLinkHelper.mm #import <UIKit/UIKit.h> #import "UnityAppController.h" @interface DeepLinkHelper : UnityAppController @end static NSMutableDictionary *pendingLinkData = nil; @implementation DeepLinkHelper // 冷启动：App未被系统运行时，从链接拉起 - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions { [super application:application didFinishLaunchingWithOptions:launchOptions]; if (pendingLinkData == nil) { pendingLinkData = [NSMutableDictionary dictionary]; } // URL Scheme冷启动时，参数在launchOptions里的UIApplicationLaunchOptionsURLKey NSURL *url = launchOptions[UIApplicationLaunchOptionsURLKey]; if (url) { [self handleDeepLinkURL:url]; } return YES; } // 热启动：App在后台，通过URL Scheme被拉起 - (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary<UIApplicationOpenURLOptionsKey,id> *)options { [self handleDeepLinkURL:url]; return YES; } // Universal Links冷启动和热启动共用 - (BOOL)application:(UIApplication *)application continueUserActivity:(NSUserActivity *)userActivity restorationHandler:(void (^)(NSArray<id> *restorationObjects))restorationHandler { if ([userActivity.activityType isEqualToString:NSUserActivityTypeBrowsingWeb]) { NSURL *url = userActivity.webpageURL; [self handleDeepLinkURL:url]; } return YES; } - (void)handleDeepLinkURL:(NSURL *)url { if (url == nil) return; NSMutableDictionary *params = [NSMutableDictionary dictionary]; params[@"absoluteString"] = url.absoluteString ?: @""; params[@"scheme"] = url.scheme ?: @""; params[@"host"] = url.host ?: @""; params[@"path"] = url.path ?: @""; // 解析query参数，例如 ?scene=shop&goods_id=10086 NSURLComponents *components = [NSURLComponents componentsWithURL:url resolvingAgainstBaseURL:NO]; for (NSURLQueryItem *item in components.queryItems) { if (item.name && item.value) { params[item.name] = item.value; } } // 存入暂存区 if (pendingLinkData == nil) { pendingLinkData = [NSMutableDictionary dictionary]; } [pendingLinkData removeAllObjects]; [pendingLinkData setDictionary:params]; // 如果Unity已经就绪，发送消息； // 如果还没就绪，等C#侧主动来拉 [self trySendToUnity]; } - (void)trySendToUnity { if (pendingLinkData.count == 0) return; // 需要确认unityReady标记，这个标记由C#侧在Start/Enable时置为1 BOOL isUnityReady = [self isUnityReadyFlag]; if (!isUnityReady) { // 延时重试，避免Unity在启动过程中的早期阶段收不到消息 dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(0.5 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{ [self trySendToUnity]; }); return; } // 序列化成JSON字符串，一次性丢给C# NSError *error = nil; NSData *jsonData = [NSJSONSerialization dataWithJSONObject:pendingLinkData options:0 error:&error]; if (!jsonData) return; NSString *jsonString = [[NSString alloc] initWithData:jsonData encoding:NSUTF8StringEncoding]; [[NSUserDefaults standardUserDefaults] setObject:jsonString forKey:@"deep_link_pending_json"]; [[NSUserDefaults standardUserDefaults] synchronize]; const char *objName = "DeepLinkBridge"; const char *methodName = "OnNativeMessage"; const char *param = jsonString.UTF8String; // C#侧签名：public void OnNativeMessage(string json) UnitySendMessage(objName, methodName, param); }

这段代码的思路很明确：不管哪种渠道唤醒，都把原始URL和解析好的query参数放进一个字典，先暂存，再判断Unity是否就绪，就绪就发，没就绪就0.5秒重试一次。

3.2 Unity侧C#接收与主动拉取

原生层发消息只是一个方向，我更推荐C#侧同时做启动时主动拉取，双保险。

// Assets/Scripts/DeepLinkBridge.cs using System.Collections; using System.Collections.Generic; using UnityEngine; public class DeepLinkBridge : MonoBehaviour { public static DeepLinkBridge Instance { get; private set; } private bool _messageHandled = false; void Awake() { if (Instance != null && Instance != this) { Destroy(gameObject); return; } Instance = this; DontDestroyOnLoad(gameObject); } void Start() { // 场景初始化完成后，从原生层拉取暂存数据 StartCoroutine(PullPendingLinkFromNative()); // 同时订阅热启动事件 Application.deepLinkActivated += OnDeepLinkActivated; } void OnDestroy() { Application.deepLinkActivated -= OnDeepLinkActivated; } private IEnumerator PullPendingLinkFromNative() { yield return new WaitForSeconds(0.3f); #if UNITY_IOS && !UNITY_EDITOR string pending = PullPendingJsonFromNative(); #else string pending = null; #endif if (!string.IsNullOrEmpty(pending)) { OnNativeMessage(pending); } } // 原生层通过UnitySendMessage调到这里 public void OnNativeMessage(string jsonString) { if (string.IsNullOrEmpty(jsonString)) { return; } // 重复消息保护：同一个链接处理过一次就不再处理 if (_messageHandled) { Debug.Log("[DeepLink] 消息已处理，忽略重复回调"); return; } JsonData data = JsonMapper.ToObject<JsonData>(jsonString); string absoluteUrl = (string)data["absoluteString"]; Debug.Log("[DeepLink] 收到唤醒链接: " + absoluteUrl); // 这里根据业务场景分发 ProcessDeepLink(data); _messageHandled = true; } private void OnDeepLinkActivated(string url) { // 这是Unity引擎自带的热启动回调，适用于Universal Links部分场景 Debug.Log("[DeepLink] Unity内置回调: " + url); ProcessUrlString(url); } [System.Runtime.InteropServices.DllImport("__Internal")] private static extern string PullPendingJsonFromNative(); }

这里要注意Application.deepLinkActivated这个API是Unity 2019.3之后才有的，可以在C#侧直接收到部分场景的Deep Link回调。但实测下来并不完全可靠，冷启动时它偶尔会错过，所以我坚持原生层暂存 + C#侧主动拉取的方案作为主路径，Unity内置回调当辅助。

4. Universal Links配置实操：从域名到AASA文件一次说透

Universal Links的配置明显比URL Scheme啰嗦得多，但也是归因和广告投放最常用的路径。配置失败的症状几乎都长一个样：链接在Safari里打开，顶上出现一个"打开App"的横幅，点一下也能跳，但就是不自动拉起，体验差了一大截。

4.1 域名关联与AASA文件细节

第一步，在Xcode的Signing & Capabilities里添加Associated Domains，填上applinks:你的域名，比如applinks:cb95f.example.com。注意不要带https://前缀。

第二步，把AASA文件放到域名的根目录或者/.well-known/目录下，两者选一个就行。文件格式要求iOS 9之后必须是JSON，不带签名。下面是我实际用的一份：

{ "applinks": { "apps": [], "details": [ { "appID": "TEAMID.com.yourcompany.yourgame", "paths": ["*"] } ] } }

TEAMID替换成你在开发者后台看到的Team ID（一串10位的字母数字），com.yourcompany.yourgame替换成你的Bundle Identifier。

有一个坑很多人踩过：paths字段建议用带具体路径的写法，比如["/event/*", "/invite/*"]，不要一上来就*。原因有两个。第一是安全考量，反正你也不希望随便一个域名下的链接都能拉起你的App吧？第二个原因是AASA文件的匹配规则不支持URL编码之后的模糊匹配，如果你把*改成精确路径，后面排查问题反而容易很多。

4.2 AASA文件可验证性与缓存问题

配置完AASA文件之后，不要急着在Safari里测试。先用https://你的域名/apple-app-site-association或者https://你的域名/.well-known/apple-app-site-association直接访问，看返回的JSON内容是否和上面一致。

最关键的验证方式是让iOS系统刷新对AASA文件的信任。系统默认缓存时效是不定的，有时候改了文件要等很久才能生效。测试前可以采用这个土办法：关掉Safari的全部标签页，再清掉Safari缓存，然后进设置里开飞行模式再关掉；实在不行就重启手机。多试几次，确保你的测试设备和理论上的缓存周期错开。

另外提醒一句，如果你的域名用了CDN加速，要确认CDN节点正确地返回了AASA文件，而且响应头里不要有奇怪的拦截规则。我见过一个项目，AASA文件返回了200，但Content-Type是text/html，iOS直接判定格式非法，花了两天才查出来。

4.3 ATS与容错回退

Universal Links走的是标准的HTTPS请求，如果你的App确实要允许HTTP请求，在Info.plist里配置NSAppTransportSecurity的NSAllowsArbitraryLoads为YES。不过这里我强烈建议不要为了省事就全开，而是用NSExceptionDomains精确控制。否则审核可能被拒，别问我怎么知道的。

还有一层兜底逻辑别漏：Universal Links按系统规则应该直接拉起App，但如果用户从某些WebView内点击，或者因为各种奇怪的系统原因没有拉起，你应该让链接对应的H5落地页去执行一次URL Scheme跳转，作为回退。很多手游是这样设计的：落地页检测到App没有通过Universal Links被拉起，就生成一个mygame://的URL Scheme链接给用户点，点了系统弹窗确认后再进游戏。这套双保险，能兜住Universal Links各种意料之外的失效情况。

5. 参数规范设计：不要让C#层变成万国语言翻译器

把链接参数往C#层丢完之后，真正的业务灾难才刚开始。很多团队的原生层写得没问题，但C#层解析和分发一团乱，最后游戏里活动跳转全是Bug。

5.1 参数命名和序列化规范

先约法三章：

• 所有参数名统一小驼峰，比如goodsId、sceneType，不要出现goods_id和goodsId混用
• 参数解析统一在DeepLinkBridge里处理，别的脚本不允许直接解析原生JSON
• 所有链接参数的值一律视为字符串，数值类型转换在业务层做，原生层不做类型推断

我习惯定义一套统一的分发协议，举个例子：

{ "absoluteString": "mygame://invite?inviter=UID_12345&serverId=3001", "scheme": "mygame", "host": "invite", "path": "", "inviter": "UID_12345", "serverId": "3001" }

C#层拿到这个JSON之后，看host或者path就知道用户被唤醒是为了什么。mygame://invite表示邀请裂变，https://www.mygame.com/shop/goods?goodsId=10086表示商品跳转。后续所有新增场景都往这个结构里填，解析逻辑不用大改。

5.2 中文和特殊字符的编码陷阱

这里必须单独拎出来说，因为我在这个上面翻过车。

URL里的query参数，如果包含中文、空格、&等保留字，链接在生成那一刻就应该做一次URL编码。原生层拿到的URL是已经被编码过的，比如中文"签到"会被编成%E7%AD%BE%E5%88%B0。如果你的C#层直接拿absoluteString做字符串匹配，一定会踩坑。

做一个统一的解码处理，放在原生层解析时顺手做掉。用上面3.1代码的思路，NSURLComponents.queryItems本身就自动解码了，所以拿到params[@"inviter"]的时候已经是正常的中文文本了。前提是你不要再用absoluteString去做字符串匹配，要在params字典里取值。

还有URL编码的经典误区：链接里如果带的是%本身，比如业务参数里的字符串带有百分号，你直接URLDecode两次会把%25这种合法内容也解掉，出来的跟你预期的不一样，所以解码只做一次。这个鬼问题排查起来非常隐蔽。

5.3 安全校验不能省

Deep Link被调用的安全性问题，在手游里尤其突出。你的链接协议一旦泄漏，别人可以伪造一条mygame://recharge?count=99999丢到玩家群里，如果你的C#层不校验合法性直接处理，后患无穷。

我一般在原生层和C#层各做一道校验：

• 原生层：校验URL的host和path是否在白名单内，非法直接丢弃
• C#层：校验关键参数（比如服务器ID、玩家ID格式），对不上就进入通用落地页而不是具体活动页

虽然对纯客户端来说，逆向破解终归防不住，但该做的拦截一定要做，别把安全底线放在一个小孩子都能改的URL参数上。

6. 全链路真机测试：每种唤醒路径都要手动过一遍

代码写完了，配置好了，最痛苦的是验证。Xcode模拟器对Universal Links的支持还行，但真机上才能暴露ATS、缓存、系统弹窗这些真问题。这里给出一套亲测有效的测试流程。

6.1 测试用例拆解

按照两个维度做矩阵：唤醒方式是URL Scheme还是Universal Links，App状态是冷启动、热启动还是后台挂起。

我建议每项都测，不要偷懒。因为：

• 冷启动 + URL Scheme，测的是launchOptions分支
• 热启动 + URL Scheme，测的是openURL分支
• 冷启动 + Universal Links，测的是didFinishLaunchingWithOptions + continueUserActivity分支
• 热启动 + Universal Links，测的是continueUserActivity分支
• App在前台时点击链接，iOS可能只走continueUserActivity，热启动和前台不一致，也要分开测

6.2 快速构造测试链接的方法

真机测试不需要写一个完整的H5页面。测试URL Scheme的时候，直接在Safari地址栏输入mygame://invite?inviter=UID_12345&serverId=3001回车，系统弹窗点允许，就能拉起App。

测试Universal Links的时候，Safari地址栏输入完整的HTTPS链接，比如https://www.mygame.com/invite?inviter=UID_12345，看是否自动拉起App。如果只是顶部出现横条，说明AASA文件识别有问题，优先检查域名关联和文件格式。

我建议再准备一个iCloud备忘录，把测试链接都存下来，真机测试时打开备忘录点链接，比在Safari里反复输入方便得多。而且备忘录内点链接的环境跟很多社交App内点击链接很像，更能暴露Universal Links在非Safari环境下的兼容性问题。

6.3 日志验证法：C#层和原生层日志对照

调试Deep Link，光靠肉眼看现象不够，你得确认参数到底走到哪一步丢了。

我在原生层的关键节点都打了NSLog，在C#层也打Debug.Log，然后用Xcode连真机直接看完整日志。对照原则是这样的：

• 原生层打印了URL，C#层没有打印，说明是UnitySendMessage时目标接收器没就绪，或者消息在发送前被吞了
• 原生层没打印，说明系统压根没回调到你的方法，优先检查Capabilities配置、AASA文件、回调方法签名
• C#层收到了但业务层没反应，说明参数分发逻辑有问题

另外提醒一句，continueUserActivity这个方法必须在restorationHandler这个参数存在时调用super方法，否则在某些场景下会导致Universal Links回调失效。这个坑在Unity改写过原生AppController的时候很容易翻车。

7. 上线后仍然会遇到的边界问题：几个真实踩坑记录

最后这部分，聊聊我经历过的几个"线上才会触发的隐性坑"。这些情况在测试期往往发现不了，但上线后玩家一多，各种机型、各种系统版本一混，问题就全冒出来了。

7.1 用户点击链接但App已安装未升级

应用商店的版本更新不是所有人都会及时点的。如果你的App老版本不支持新的Deep Link参数，或者老版本压根没接Deep Link，那么Universal Links点击后，iOS会走网页兜底，页面应该自己去判断"当前App版本是否过低"，然后提示用户升级，而不是干巴巴地等一个永远不会发生的唤醒。

这个判断怎么做？在舱底页里用JavaScript读取navigator.userAgent里的App版本号，跟当前活动链接的最低版本需求做比对。版本号对不上就弹升级引导，而不是尝试唤醒。

7.2 冷启动时的C#脚本执行顺序

两个场景都在调DontDestroyOnLoad的接收脚本，而且都依赖第一个场景初始化完毕。但Unity在冷启动时，Awake和Start的执行时机取决于你的场景加载顺序和脚本执行顺序。如果你的接收脚本被挂在第一个场景的某个UI节点上，而第一个场景是多场景叠加的，接收脚本可能晚于原生层第一次发消息。

所以前面的双保险设计才那么重要。原生层延时重试，C#层主动拉取，两边互相覆盖，等第一个场景加载完成之后参数就不会丢了。不要试图省掉这条主动拉取逻辑，我吃过这个亏：某个版本改动后原生层发消息过早，C#侧又没拉，结果线上开服活动玩家点了链接进来全落在冷冰冰的主界面上，活动面板压根没弹。

7.3 iOS系统更新后的行为漂移

iOS版本升级有时候会悄悄改变某些API的行为。Deep Link相关的API算稳定，但有一年iOS的系统更新对Universal Links的缓存刷新策略做了调整，导致很多玩家反映"更新系统之后点链接不拉起App了"。这不是你的代码出了问题，是系统缓存策略变了。

处置思路是：遇到这类问题，优先怀疑系统缓存，引导玩家从Safari地址栏手动输入一次链接（相当于强刷一次关联验证），往往就能恢复。别一上来就改代码、改AASA文件，先让玩家试这个操作。

7.4 参数里嵌套业务场景的黏性问题

最后说个偏产品层面的事。Deep Link不只是"打开App"这一步，真正的价值在于把用户直接送到他想去的页面。你收到一条scene=shop&goodsId=10086的链接，游戏里就应该真的跳到那个商品详情页，而不是只回主界面。

很多团队在这里会做"等首场景Idle后再处理"的操作，为了确保场景、UI框架、数据层都准备好了。这个思路对，但要注意处理超时和失败回退。我等了3秒场景没好，就直接进主界面，别再傻傻等下去。否则玩家会觉得自己点的链接石沉大海。

提示：建议把Deep Link的处理入口收敛到一个独立的C#脚本里，不要在多个场景各自实现一套解析。维护成本低，排查问题也方便得多。

8. 写在最后的经验沉淀

把Unity手游的iOS Deep Link全链路走通之后，最大的体会是：这个功能90%的坑不在原理，而在时序和配置细节。原生层的参数转发、Unity侧的接收时机、AASA文件的服务端配置，这三件事只要有一件没衔接好，线上就会有一批玩家点链接"无声无息"。

我的建议很简单：如果项目还在早期，就把Deep Link接入量化为一个正式任务来做，不要塞到上线前最后一周才匆忙接。上线前务必把测试用例矩阵跑一遍，把冷启动、热启动、两种链接方式、版本回退全部过一遍，日志逐条对照。

如果你现在正在被唤醒链路折磨，照着这篇文章的流程重头梳理一遍：先确认选型，再验证原生层是否真的收到URL，再看C#层接收时机，最后检查AASA文件。技术本身不算深，但每个环节都有它的小脾气，摸顺了就好。