Unity手游iOS Deep Link接入实战：从配置到踩坑全解析

1. 先理清楚：手游的 Deep Link 两个唤醒通道，到底差在哪

我看过太多 Unity 项目在上线买量或者做社交分享回流的时候，才急急忙忙来找 Deep Link 方案。其实也不怪大家，做手游客户端的，平时注意力都在玩法、UI、性能这些地方，Deep Link 属于典型的"运营要的时候很急，平时完全想不起来"的功能。

先说我自己的场景。之前接的一个模拟经营类项目，运营要做 iOS 买量归因，还要做老玩家邀请新玩家的分享回流。分享出去一张卡片，卡片上带着邀请人的 ID，用户点开之后，如果手机上装了游戏就直接唤起进入游戏；没装的话就落到 App Store 下载页。听起来很常规对不对？但实际上手才发现，从 iOS 系统层到 Unity C# 层，中间每个环节都有坑，尤其冷启动（App 被杀了之后通过链接唤起）和热启动（App 在后台被唤起）两条路径的处理方式完全不同。

Deep Link 在 iOS 上的核心价值，简单说就是：给游戏加一根"带有参数的直达通道"。用户点一个链接，不仅能打开你游戏，还能立刻知道这个用户是从哪个渠道来的、带着什么参数进来的。比如game123://open?page=activity&id=10086，其中game123是你的 URL Scheme，page=activity是要直达的活动页，id=10086是渠道或邀请人标识。

但 iOS 上能做 Deep Link 的通道有两条，很多人一开始直接混在一起用：

我的结论很直接：两个通道都要接。Universal Links 做主通道，用户体验好、能做"未安装降级到网页"；URL Scheme 做兼容兜底，因为国内很多第三方广告平台的点击跳转，到现在还是只支持 scheme 拉起。只接一个的话，买量归因这条线迟早出问题。

2. 工程侧配置：Info.plist 与 Associated Domains 的正确姿势

2.1 URL Scheme 注册：Info.plist 里要写什么

在 Unity 工程的 iOS 构建产物里，找到Info.plist，往CFBundleURLTypes数组里加一项：

<key>CFBundleURLTypes</key> <array> <dict> <key>CFBundleURLName</key> <string>com.yourcompany.yourgame</string> <key>CFBundleURLSchemes</key> <array> <string>game123</string> </array> </dict> </array>

这里game123就是你给这个 App 定的 URL Scheme。用户访问game123://xxx时，系统会优先找 scheme 为game123的已安装 App。

Scheme 的命名我有几个习惯：

• 尽量短，因为广告平台回传的链接都是字符串，越短越不容易被截断或转义出错。
• 不要用太通用的词，比如game、open，全终端不知道多少 App 注册了game://，一旦冲突，iOS 会弹窗让用户选，转化率直接掉一截。
• 如果公司有多个游戏，最好统一命名规范，比如game123、game456，运维和投放那边也好记。

顺带一提，很多人不知道的一点：在 iOS 9 之后，系统从 Safari 唤起 URL Scheme 会弹一次确认框，这个确认框对买量转化影响非常大。用户明明点了广告，结果还要再点一次"打开"，很多人就在这一步流失了。这也是为什么 Universal Links 在 iOS 9 推出之后，主流做法马上就切了过去。

2.2 Universal Links 三件套：开发者后台、Entitlements、AASA 文件

Universal Links 配置涉及三层，缺一不可，我按顺序说：

第一层：Apple Developer 后台开启 Associated Domains

在 Certificates, Identifiers & Profiles 里找到你的 App ID，打开Associated Domains能力，保存。这一步不做，后面 Xcode 里配置了也白搭。

第二层：Xcode 工程添加 applinks 域名

在 Xcode 的 Signing & Capabilities 里加Associated Domains，填入：

applinks:yourdomain.com

注意这个域名是你自己的 HTTPS 服务器域名，最好单独准备一个短链域名，因为 AASA 文件的校验和广告平台回传时，都会用到它。

第三层：服务器放置 AASA 文件

在域名根目录放一个apple-app-site-association文件，路径要求是https://yourdomain.com/apple-app-site-association，内容长这样：

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

appID的格式是团队ID.BundleID，TeamID在开发者后台能看到。paths里面写的是允许唤起 App 的路径规则，"*"表示所有路径都放行。

我之前就因为路径配置吃过亏。AASA 的paths匹配是大小写敏感的，而且只能匹配 path 部分。如果你某个活动路径是https://yourdomain.com/act/Summer2024，而 AASA 里写的是/act/*，那没问题；但如果你写成/ACT/*，iOS 匹配不上，链接就只在 Safari 里打开，App 不会被唤起。

另外，AASA 文件有三个硬性要求：

• 必须是 HTTPS 访问，而且不能有重定向。中间哪怕跳一次 HTTP 地址，iOS 都会直接判定无效。
• Content-Type 官方没有强制统一，但建议服务器返回application/json，很多后台服务器默认把文件当 octet-stream 也能用，不过我用下来稳妥起见还是显式设置。
• 文件里不能有多余字符，严格符合 JSON 格式。之前有一个同事手动在文件末尾多敲了个空行，结果真机上整整半小时测不出来，最后排查到是 AASA 解析失败。

2.3 用 PostProcessBuild 让配置自动落进 Xcode 工程

手动改 Info.plist 和 Entitlements 的问题很明显：Unity 每次 Build 都会生成新的 Xcode 工程，你上一次手动配置的东西全部被覆盖。所以我的项目里都写了PostProcessBuild脚本。

核心思路是在构建完成后，自动往工程里做三件事：写 Info.plist 的 URL Scheme、写 Entitlements 关联域名、把原生 Deep Link 代码文件打进工程。

大概框架长这样：

#if UNITY_IOS using UnityEditor; using UnityEditor.Callbacks; using UnityEditor.iOS.Xcode; using System.IO; public class DeepLinkPostProcess { [PostProcessBuild(100)] public static void OnPostProcessBuild(BuildTarget target, string path) { if (target != BuildTarget.iOS) return; string projectPath = PBXProject.GetPBXProjectPath(path); PBXProject project = new PBXProject(); project.ReadFromFile(projectPath); string targetGuid = project.GetUnityMainTargetGuid(); // 1. Info.plist 注册 URL Scheme string plistPath = path + "/Info.plist"; PlistDocument plist = new PlistDocument(); plist.ReadFromFile(plistPath); PlistElementArray urlTypes = plist.root.CreateArray("CFBundleURLTypes"); PlistElementDict urlType = urlTypes.AddDict(); urlType.SetString("CFBundleURLName", "com.yourcompany.yourgame"); PlistElementArray schemes = urlType.CreateArray("CFBundleURLSchemes"); schemes.AddString("game123"); plist.WriteToFile(plistPath); // 2. Entitlements 关联域名 string entitlementsPath = path + "/Unity-iPhone.entitlements"; PlistDocument entitlements = new PlistDocument(); entitlements.ReadFromFile(entitlementsPath); PlistElementArray associatedDomains = entitlements.root.CreateArray("com.apple.developer.associated-domains"); associatedDomains.AddString("applinks:yourdomain.com"); entitlements.WriteToFile(entitlementsPath); project.AddFile(entitlementsPath, "Unity-iPhone.entitlements"); project.WriteToFile(projectPath); } } #endif

脚本里还应该把DeepLinkAppController.h和.mm文件加进 Xcode 工程，并把UnityAppControllerClassName写到 Info.plist 里。这个键是什么、为什么必须加，下面详细说。

3. 原生层拦截：继承 UnityAppController 接管系统回调

3.1 为什么必须动 UnityAppController

Unity 生成的 iOS 工程里，真正的 AppDelegate 是UnityAppController。系统收到 Deep Link 之后，所有回调都会先走到这个类再被 Unity 内部处理。

我们要接自定义逻辑，就得在系统回调打到自己游戏逻辑之前，把 URL 参数截下来，否则等 Unity 内部消化完了，你很难在 C# 层拿到完整参数。

Unity 官方留了一个扩展点：Info.plist 里加一个UnityAppControllerClassName键，值写你的自定义类名，Unity 启动时会把UnityAppController换成你的子类。这个比手动改main.mm干净得多，不会被构建覆盖。

我的做法是这样，新建一个DeepLinkAppController.h：

#import "UnityAppController.h" @interface DeepLinkAppController : UnityAppController /// 最近一次收到的深链原始 URL，冷启动时会先缓存到这里 @property (nonatomic, copy) NSString *pendingDeepLink; /// 清理缓存的深链参数 - (void)clearPendingDeepLink; @end

对应的.mm文件：

#import "DeepLinkAppController.h" #import <UIKit/UIKit.h> extern "C" const char* UnityGetCachedDeepLink() { DeepLinkAppController *delegate = (DeepLinkAppController *)[UIApplication sharedApplication].delegate; if (delegate.pendingDeepLink.length > 0) { return strdup(delegate.pendingDeepLink.UTF8String); } return strdup(""); } extern "C" void UnityClearCachedDeepLink() { DeepLinkAppController *delegate = (DeepLinkAppController *)[UIApplication sharedApplication].delegate; delegate.pendingDeepLink = nil; } @implementation DeepLinkAppController - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions { NSURL *url = launchOptions[UIApplicationLaunchOptionsURLKey]; if (url != nil) { self.pendingDeepLink = url.absoluteString; } NSUserActivity *activity = launchOptions[UIApplicationLaunchOptionsUserActivityDictionaryKey]; if (activity != nil) { NSUserActivity *userActivity = activity[@"UIApplicationLaunchOptionsUserActivityKey"]; if ([userActivity.activityType isEqualToString:NSUserActivityTypeBrowsingWeb]) { self.pendingDeepLink = userActivity.webpageURL.absoluteString; } } return [super application:application didFinishLaunchingWithOptions:launchOptions]; } - (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary<UIApplicationOpenURLOptionsKey, id> *)options { if (url != nil) { self.pendingDeepLink = url.absoluteString; [self sendDeepLinkToUnity:url.absoluteString]; } return [super application:app openURL:url options:options]; } - (BOOL)application:(UIApplication *)application continueUserActivity:(NSUserActivity *)userActivity restorationHandler:(void (^)(NSArray<id<UIUserActivityRestoring>> * _Nullable))restorationHandler { if ([userActivity.activityType isEqualToString:NSUserActivityTypeBrowsingWeb]) { NSURL *url = userActivity.webpageURL; if (url != nil) { self.pendingDeepLink = url.absoluteString; [self sendDeepLinkToUnity:url.absoluteString]; } } return [super application:application continueUserActivity:userActivity restorationHandler:restorationHandler]; } - (void)sendDeepLinkToUnity:(NSString *)rawURL { NSDictionary *payload = @{ @"url": rawURL ?: @"", @"ts": @([[NSDate date] timeIntervalSince1970]) }; NSError *error = nil; NSData *data = [NSJSONSerialization dataWithJSONObject:payload options:0 error:&error]; if (error != nil || data == nil) { return; } NSString *json = [[NSString alloc] initWithData:data encoding:NSUTF8StringEncoding]; UnitySendMessage("DeepLinkManager", "OnDeepLinkReceived", json.UTF8String); } @end

这段代码你应该已经看出几个关键设计：冷启动时只缓存、不推送，因为 Unity 引擎还没起来，推了也丢；热启动（App 在后台）时收到新链接，才立刻通过UnitySendMessage推给 C# 层。

3.2 冷启动与热启动的两条路径差异

冷启动和热启动的处理逻辑天然不同，我给项目里的同事讲的时候喜欢打个比方：

• 冷启动相当于你刚要进电影院，检票员（系统）把票（URL）递给你，但你还没坐到座位上，这时候喊"开始看电影"是没用的。你要先把票攥在手里，等坐下之后再掏出来看。
• 热启动相当于电影看了一半，有人从后门递了张纸条进来（新 URL），你直接看一眼纸条就知道接下来该干嘛。

代码里面对应就是：

• didFinishLaunchingWithOptions里只把 URL 存进pendingDeepLink，等 C# 侧启动后主动来取。
• openURL:options:和continueUserActivity:restorationHandler:里先更新缓存，再立刻sendDeepLinkToUnity。

这个双通道设计非常关键，少了任何一边都会出问题。

3.3 参数标准化：把 NSURL 整理成 C# 侧方便消费的 JSON

原生层拿到的是NSURL，我在发给 C# 之前，会先组装成一个 JSON 字符串。这样 C# 侧不管是用LitJson、Newtonsoft.Json还是JsonUtility，都能直接反序列化成结构体，不用自己拼字符串。

注意 JSON 序列化的时候，我故意没有开NSJSONWritingPrettyPrinted，因为格式化之后会多出大量空格和换行，经UnitySendMessage传过去后再解析反而容易出问题，紧凑格式才是最稳的。

参数里面我加了一个ts时间戳，用来做重复消息去重。这个后面讲踩坑时细说。

4. 把参数送进 C# 层：UnitySendMessage 的时序陷阱与双通道方案

4.1 UnitySendMessage 的调用约定

原生层调 C# 层，最常用的就是UnitySendMessage，三个参数：

UnitySendMessage("GameObjectName", "MethodName", "messageString");

对应 C# 侧的要求是：

• 名为GameObjectName的 GameObject 必须存在且处于激活状态。
• MethodName必须是该 GameObject 某个组件上公开的方法。
• 方法签名固定是void MethodName(string param)。
• GameObject 挂的组件要继承MonoBehaviour。

我见过很多人在这里踩坑：GameObject 叫DeepLinkManager，方法也写在DeepLinkManager.cs里，但脚本挂载的 GameObject 在场景里被别的逻辑给 SetActive(false) 了，结果原生层怎么调都没反应，还不报错。排查起来特别浪费时间。

为了规避这个问题，我一般不用场景里的 GameObject，而是用DontDestroyOnLoad运行时创建常驻节点。这样做还有个附带好处：无论从哪个场景被唤起，深链处理器都一定存在。

4.2 冷启动丢消息问题：原生缓存 + C# 主动拉取

UnitySendMessage 对冷启动有一个致命限制：消息发出去时，如果 C# 脚本还没准备好，消息就丢了。而didFinishLaunchingWithOptions调用的时候，Unity 引擎还在启动阶段，C# 的Awake压根没执行。

所以冷启动这条路，我从来不在原生层主动推，而是反过来：C# 层启动完成后，主动向原生层拉取缓存。

原生层提供两个导出函数：

extern "C" const char* UnityGetCachedDeepLink(); extern "C" void UnityClearCachedDeepLink();

C# 侧对应这样写：

#if UNITY_IOS && !UNITY_EDITOR using System.Runtime.InteropServices; [DllImport("__Internal")] private static extern string UnityGetCachedDeepLink(); [DllImport("__Internal")] private static extern void UnityClearCachedDeepLink(); #endif

这里有个细节：DllImport的入口点名字要和原生导出函数名完全一致，C++ 混编时注意 extern "C"，否则会被名字改编。

C# 侧启动逻辑放在Awake里就行：

private void Awake() { if (_instance != null) { Destroy(gameObject); return; } _instance = this; DontDestroyOnLoad(gameObject); #if UNITY_IOS && !UNITY_EDITOR string cached = UnityGetCachedDeepLink(); if (!string.IsNullOrEmpty(cached)) { _pendingQueue.Enqueue(cached); UnityClearCachedDeepLink(); } #endif }

拉取后立刻清缓存，这步很关键。不然下次冷启动时又会取到上一条旧链接，导致用户启动游戏四秒后突然被拉去一个活动页，体验极差。

4.3 C# 侧 DeepLinkManager：队列、防重、分发设计

完整的管理器我习惯这么组织：

using System; using System.Collections.Generic; using UnityEngine; public class DeepLinkManager : MonoBehaviour { public static DeepLinkManager Instance { get; private set; } private readonly Queue<string> _pendingQueue = new Queue<string>(); private readonly HashSet<string> _processedCache = new HashSet<string>(); private void Awake() { if (Instance != null) { Destroy(gameObject); return; } Instance = this; DontDestroyOnLoad(gameObject); #if UNITY_IOS && !UNITY_EDITOR string cached = UnityGetCachedDeepLink(); if (!string.IsNullOrEmpty(cached)) { EnqueueRawLink(cached); UnityClearCachedDeepLink(); } #endif } private void Update() { if (_pendingQueue.Count == 0) { return; } while (_pendingQueue.Count > 0) { string raw = _pendingQueue.Dequeue(); ProcessDeepLink(raw); } } public void OnDeepLinkReceived(string json) { #if UNITY_IOS && !UNITY_EDITOR EnqueueRawLink(json); #endif } private void EnqueueRawLink(string raw) { _pendingQueue.Enqueue(raw); } private void ProcessDeepLink(string raw) { // 解析并分发 } }

热启动时，原生层通过UnitySendMessage("DeepLinkManager", "OnDeepLinkReceived", json)推送过来，方法名字和 GameObject 名字都要严格匹配。

队列的写法，保证了不管消息是启动时拉取的、还是运行中推送的，都在主线程Update里统一处理，不会中途打断正在进行的 UI 操作。

5. 场景落地：从收到 Deep Link 到完成跳转

5.1 参数解析：原始 URL 还是解析后的字典

原生层虽然已经把完整 URL 包进了 JSON，但我不建议在 C# 侧直接string.Split去解析 URL，太脆弱了。正确做法是先把整个 URL 拆成结构化对象，再进行分发。

我常用的结构体：

public struct DeepLinkPayload { public string RawUrl; public string Scheme; public string Host; public string Path; public Dictionary<string, string> Query; public static bool TryParse(string raw, out DeepLinkPayload payload) { payload = default; if (string.IsNullOrEmpty(raw)) { return false; } if (!Uri.TryCreate(raw, UriKind.Absolute, out Uri uri)) { return false; } payload.RawUrl = raw; payload.Scheme = uri.Scheme; payload.Host = uri.Host; payload.Path = uri.AbsolutePath; payload.Query = new Dictionary<string, string>(); string query = uri.Query.TrimStart('?'); foreach (string pair in query.Split('&')) { if (string.IsNullOrEmpty(pair)) { continue; } string[] kv = pair.Split('='); if (kv.Length == 2) { payload.Query[Uri.UnescapeDataString(kv[0])] = Uri.UnescapeDataString(kv[1]); } } return true; } }

为什么用Uri.TryCreate而不是手切？因为 URL 里的 query 可能包含编码过的中文字符、&符号、=符号，手切很容易出错。Uri类能帮你做好绝大多数字符处理。

5.2 分发热点：活动页、邀请关系绑定、商城直达

拿到结构化的DeepLinkPayload之后，我一般会根据 Host 和 Path 做路由分发。拿我那个模拟经营项目举例，实际遇到的深链类型包括：

C# 侧分发逻辑写成这样：

private void ProcessDeepLink(string raw) { if (!DeepLinkPayload.TryParse(raw, out DeepLinkPayload payload)) { Debug.LogWarning($"DeepLink 解析失败: {raw}"); return; } if (payload.Scheme != "game123" && payload.Host != "yourdomain.com") { return; } switch (payload.Host + payload.Path) { case "open/activity": JumpToActivity(payload.Query); break; case "invite/bind": BindInviteCode(payload.Query); break; case "shop/item": JumpToShopItem(payload.Query); break; default: Debug.Log($"未处理的 DeepLink: {raw}"); break; } }

分发逻辑里有一个点要注意：首启时机。很多运营场景要求"下载后从桌面点开 App，也要临时生效一次"。例如用户从广告落地页点了下载，装完首次打开游戏，希望直接跳到一个特定活动页。这个诉求不是 Deep Link 能单独解决的，因为你从桌面点图标启动时根本没有 URL 参数。我的做法是：在原生层把首次启动的launchOptions里的 URL 存下来，但用户从桌面正常启动时确实没参数，所以这个需求实际要配合安装归因 SDK（比如 AppsFlyer / Adjust）来做延迟深度链接，那是另一套体系。这里只讲从链接直接唤起这条路。

5.3 测试工具与联调方法

Deep Link 联调最怕的就是"不知道系统到底有没有唤起 App"。我平时用这几个方法组合验证：

模拟 URL Scheme 唤起

真机或模拟器都可以，在 Safari 地址栏输入：

game123://open?page=activity&id=10086

回车后会弹窗确认是否打开 App，确认后应该能进游戏并触发深链逻辑。

命令行也可以用xcrun simctl openurl booted "game123://open?page=activity&id=10086"，模拟器上这样测试比手动输入快得多。

模拟 Universal Links 唤起

Universal Links 不好直接在地址栏输入测试，因为系统可能先走 Safari 网络加载。我一般准备一个测试 HTML 页面，页面上放一个<a href="https://yourdomain.com/open?page=activity&id=10086">链接，在 Safari 里点这个链接。如果 AASA 生效且 App 已安装，会直接唤起；如果没生效，会留在 Safari 打开你的落地页。

Xcode 断点确认

在continueUserActivity和openURL方法里打断点，能明确看到走了哪个回调、URL 是什么。这比在 C# 侧打日志定位更快，因为可以直接看原生层拿到的原始参数。

AASA 生效检查

Universal Links 配置完最让人头疼的就是不知道 AASA 文件有没有被 Apple 正确抓取。可以访问：

https://app-site-association.cdn-apple.com/a/v1/yourdomain.com

这个地址返回的就是 Apple CDN 抓取到的 AASA 内容。如果这里能正常返回你的配置，那说明 Apple 已经收录了；如果这里返回失败，真机测试基本不可能通过。

6. 实战踩坑记录：参数乱码、重复回调、首启时序

6.1 中文参数在 JSON 投递时的编码翻车

这个坑我印象太深了。邀请码参数里带用户昵称，用户昵称是中文，比如code=张伟123。原生层从NSURL里取到的absoluteString，中文其实是 URL 编码过的，长这样：code=%E5%BC%A0%E4%BC%9F123。理论上这没毛病，C# 侧Uri.UnescapeDataString能还原。

问题出在另一种场景：如果投放后台给的链接里，中文参数没有被百分号编码，而是直接裸的中文，NSURL照样能创建出来，absoluteString也是正常中文。这时候组装 JSON 用的NSJSONSerialization，输出的 JSON 字符串是 UTF-8 编码的，UnitySendMessage传参时我用的json.UTF8String，C# 侧拿到手应该是正常的中文。

但我有一次在模拟器上调，C# 侧打日志看到中文全变成了乱码。排查了半天，最后发现是原生层多了一步操作：有人把NSString转NSData时用了NSASCIIStringEncoding，中文字符根本存不进 ASCII，全被替换成了?。所以记住一个原则：深链参数统一走 UTF-8，任何编码转换都别用 ASCII 相关 API。

6.2 热启动下重复收到同一条链接

Universal Links 和 URL Scheme 同时接好之后，出现了这么个情况：用户在 Safari 里点 Universal Links 唤起 App，热启动进到游戏，但深链事件被触发了两次。

最开始我以为是系统回调重复，后来打断点才发现：continueUserActivity被调用了一次，但因为我在里面调用[super application:continueUserActivity...]，Unity 内部又对同一条 Universal Link 做了一次处理，导致 C# 层被通知了两次。

解决方案分两层：

• 原生层在continueUserActivity里先检查userActivity.activityType，确认是NSUserActivityTypeBrowsingWeb再处理。
• C# 侧加上一个去重机制。我是在DeepLinkPayload里加一个由raw + ts生成的指纹，在处理前判断_processedCache里有没有同样的指纹。

其实还有更简单的做法：如果两次事件到达时间非常接近（比如 500ms 以内），后到的直接忽略。但这种方法治标不治本，用了指纹去重之后才彻底安静。

6.3 首次启动时序：DidFinish 里的缓存有效期

再强调一次这个时序问题，因为很多人最终都会栽到这里。

如果你在didFinishLaunchingWithOptions里拿到 URL 后立刻UnitySendMessage，绝大多数情况是消息发出去石沉大海。Unity 引擎此时还在加载脚本，你的DeepLinkManager还没创建。

我的处理方案是前文说的双通道，但还有一个补充细节：C# 侧主动拉取缓存之后，要立刻UnityClearCachedDeepLink()。这个我之前提到过，但这里想再展开说一个坑——如果你拉了缓存不清理，下一次冷启动（用户杀进程后从桌面图标启动）时，会把上一次的历史深链又处理一遍。用户上了游戏啥也没干，莫名其妙被拉到之前某个活动页里，非常尴尬。

6.4 真机从 Safari 跳转时系统弹窗的坑

这是 Universal Links 特有的体验问题。iOS 13 之前，从 Safari 唤起 Universal Links 时，右上角会有一个小广告栏提示"打开"，用户点了之后才进 App。iOS 13 之后苹果改了逻辑，大多数场景是直接唤起，不用再点一次。

但注意：如果你的 AASA 文件匹配不上，或者用户在 Safari 里已经对该域名主动打开了网页，iOS 很可能把后续的点击都当成普通网页浏览，不再唤起 App。

遇到这种情况，最直接的排查路径还是回到https://app-site-association.cdn-apple.com/a/v1/yourdomain.com去确认 AASA，如果 CDN 返回正常，就再检查 Entitlements 文件是否真的被 Xcode 工程引用了。我遇到过Unity-iPhone.entitlements文件加了但工程里CODE_SIGN_ENTITLEMENTS没指向它，导致签名的时候完全没带上相关能力。

线上买量归因这块，Deep Link 只是链路的一部分。就算你 Universal Links 和 URL Scheme 都配置好了，广告平台的数据回传还涉及服务端激活匹配、苹果的隐私限制这些，不在这篇文章范围里。但客户端这一层，从配置到原生拦截再到 C# 投递，走通之后至少不会在拉新和回流环节掉链子。

我现在的习惯是，每次 iOS 版本提测前，都要跑一遍深链自测清单：URL Scheme 冷启动、URL Scheme 热启动、Universal Links 冷启动、Universal Links 热启动、参数中文编码、重复回调检测。六项全过才敢提测。这套流程固定下来之后，深链基本上成了最省心的模块。