Unity手游iOS Deep Link接入：从URL Scheme到Universal Links完整实践

做手游发行或者自研项目做到一定阶段，基本都会接到这样一个需求：给游戏接一套 iOS 的 Deep Link，让买量广告、短信推广、活动 H5 页面能直接唤起 App，顺便把渠道来源、用户 ID 之类的参数带进游戏里。我在 Unity 项目里完整走了一遍从 URL Scheme 和 Universal Links 的原生配置，到 C# 层最终拿到参数的流程，中间踩了一堆文档里不会写清楚的坑。这篇文章就把整条链路拆开讲一遍，从 iOS 系统怎么把链接交给 App，到 Unity 侧怎么安全、不丢参数地接到业务层，一次说明白。不管你是正在被“运营要个唤起链接”的需求追着跑的新手，还是准备把现有唤起逻辑重构成规范方案的老手，这篇都值得花几分钟看完。

1. 整体方案：为什么手游需要两条腿走路

接触 Deep Link 之前，很多 Unity 开发者的第一反应是“这不就是给 URL Scheme 加个参数的事吗”。真上手之后会发现，手游场景下 Deep Link 从来不是一个技术点，而是一套需要和买量归因、运营活动、iOS 系统策略打配合的方案。理解这一点，后面的配置才不会跑偏。

1.1 Deep Link 在手游里的典型业务场景

手游的 Deep Link 使用频率比我刚开始做时想象的高得多。最常见的几个场景：

第一个是广告投放唤起。买量平台或者自研广告系统，在抖音、Safari、微信里投放的广告，用户点击以后希望直接跳进游戏里的指定页面，比如新用户引导、签到活动页或者某个具体玩法。这种场景里，链接后面通常会拼上一串参数，比如渠道 ID、广告计划 ID、点击 ID，方便广告系统回来归因。如果 App 没装，一般会落到 App Store 下载页，装完之后还要能通过指纹匹配把这次安装归到这次点击上——这就不是单纯的 Deep Link，而是归因链接，业内一般叫 Deferred Deep Link。

第二个是存量用户促活。运营推到用户手机上的短信、Push、邮件，里面附带的链接，点击以后跳进 App 落地页。这种对唤起成功率和参数准确性的要求极高。短信通道的用户大多是从历史包装进来的老用户，唤起失败一次，运营活动的转化率肉眼可见地掉。

第三个是端外跳端内。比如游戏里分享出去一个邀请链接，好友在微信里看到，复制到 Safari 打开，唤起游戏以后自动加好友、领奖励。这种场景下参数里可能带着分享人 ID、邀请类型、来自哪个平台，C# 侧拿到以后要立刻处理，不能等用户手动进活动页再刷新。

另外还有一类容易被忽略的场景：iOS 原生推送（notification banner）点击以后，通过 Deep Link 带一个 push 参数进游戏，用于追踪推送点击率。很多项目会把推送点击和 Deep Link 合并成一条技术链路处理，能省掉一大半重复代码。

你会发现这些场景背后有一个共同点：参数不是给人看的，是给 C# 层业务逻辑用的。这就决定了整条链路的核心是“参数怎么从系统级的 URL 里，完整、不错乱、不丢失地交到 Unity 的业务代码手上”。

1.2 URL Scheme 与 Universal Links 的取舍

iOS 上做 Deep Link，基本就两条路：URL Scheme 和 Universal Links，还有人会把两者都接上，形成双通道兜底。这两者不是替代关系，而是互补关系，但在关键场景下的表现差异巨大。

URL Scheme 是最老牌的方式。在 Info.plist 里注册一个自定义协议，比如mygame://，系统层面会把这个协议的所有打开请求都路由到你 App 上。优点就一个字：简单。不需要服务器，不需要域名，不需要 HTTPS，配置一次以后永久有效。但缺点也很明显：第一，iOS 系统对 URL Scheme 没有强制的唯一性保护，任何 App 都可以声明同一个 scheme，后装的会覆盖先装的或者弹选择框；第二，从 Safari 唤起 URL Scheme 时，如果 App 没安装，Safari 会直接弹一个“打不开网页，因为地址无效”这类错误，体验极差；第三，很多第三方 App 内置的浏览器会拦截 URL Scheme 跳转，导致唤起失败或弹窗。

Universal Links 是苹果在 iOS 9 推出的替代方案。它的思路是完全反过来的：不走自定义协议，而是用普通 HTTPS 链接。系统在用户点击一个https://你的域名/xxx链接时，会先请求你服务器上的apple-app-site-association文件（简称 AASA），验证这个域名确实授权给你这个 App ID，验证通过就把链接直接交给 App 处理，App 没装则正常打开网页，没有任何报错弹窗。体验上的提升是决定性的：没装 App 进 H5 落地页，装了 App 直接唤起，中间过程用户几乎无感。

两者对比起来，我的选择建议是：以 Universal Links 为主，URL Scheme 做兼容兜底。Universal Links 负责所有浏览器和系统级的唤起场景，URL Scheme 负责那些还没升级系统、或者部分 WebView 里 Universal Links 被判定为普通网页跳转的场景。很多大厂的广告 SDK 在内部判断时也是两条链路都探一遍，先试 Universal Links，失败再试 URL Scheme，最后通报归因结果。

但 Universal Links 的引入也意味着新的麻烦：你需要一个域名、需要 HTTPS、需要把 AASA 文件放到服务器根目录，而且文件内容的微小错误都会导致整条链路静默失败——这也是我在后面第 2 节要展开讲的。

2. iOS 原生侧配置：从工程到签名的三门功课

很多 Unity 团队在接到 Deep Link 需求时，第一反应是“Unity 不是可以直接调 iOS API 吗”，其实 iOS 侧的 Deep Link 配置和 Unity 引擎几乎无关，它涉及到的是 Xcode 工程、Info.plist、Associated Domains、服务器文件托管这些原生层面的东西。这一节把三门功课逐一说明白。

2.1 URL Scheme 配置与 Info.plist 的细节

URL Scheme 的配置位置在 Xcode 工程的 Info.plist 里，对应的 key 是CFBundleURLTypes。Unity 项目用 IL2CPP 构建后，需要在 Xcode 工程里做这个配置，或者直接改 Unity 构建生成后的Info.plist。

先看标准配置长什么样：

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

CFBundleURLName是标识符，一般用 bundle ID，没有实际功能意义；CFBundleURLSchemes才是用户真正会通过链接触发的协议名。这里有两个经验：一是 scheme 尽量短且具备品牌唯一性，yourgame和yg双配置能减少冲突概率，但别指望完全避免；二是 scheme 是大小写敏感的，最好统一小写，否则运营和投放人员在拼链接时容易踩坑。

配置完成后，你可以在真机 Safari 地址栏输入：

yourgame://open?scene=activity&actId=1001

系统会在瞬间拉起安装了该 scheme 的 App。就这个测试链路本身而言，过程是相当快的。但如果 App 没装，Safari 的报错页会让用户怀疑人生。

这里有一个容易踩的坑：Unity 构建时如果开启了“Link Other Flags”之类跟 URL 无关的选项，理论上不影响 Deep Link，但我有次在构建机上的 Xcode 工程里改了 Info.plist，重新构建后被 Unity 的 PostProcessBuild 脚本覆盖了。正确的做法是写一个 C# 的IPostProcessBuild脚本，构建后自动往 Info.plist 里注入 CFBundleURLTypes。只要脚本跑一次，就不会再被人手改坏。

2.2 Universal Links 配置：Associated Domains 与 AASA 文件

Universal Links 的配置分为两部分：App 侧和服务器侧。

App 侧，打开 Xcode 工程，找到 Signing & Capabilities，添加 Associated Domains 能力，在里面添加：

applinks:yourdomain.com

注意这里不是 https:// 前缀，而是固定的applinks:。如果有多个域名（比如主域和备用域），每行一个。

服务器侧，需要把 AASA 文件放到你的 HTTPS 域名根目录下，路径是：

https://yourdomain.com/apple-app-site-association

文件格式是 JSON，没有 .json 后缀，苹果要求的是标准文件名。内容结构：

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

这里配了两个关键字段：appID是你 App 的 Team ID 加 Bundle ID，paths是允许唤起 App 的路径模式。注意 paths 支持通配符*，但如果你遇到某个带有.的路径匹配不上，要么把*换成具体的路径前缀，要么检查服务器是否把 AASA 当成了静态文件输出。

配置完成后，有一个关键步骤必须要做：验证 AASA 是否被苹果正确拉取。方法是在真机 Safari 打开你的域名链接，然后用 iOS 配置描述文件以外的另一条验证路径：访问以下地址：

https://yourdomain.com/apple-app-site-association

直接用浏览器打开这个文件，看返回的 JSON。如果返回的是首页 HTML 或者 404，说明服务器托管有问题。更严谨的做法是用 Xcode 的simctl模拟器验证，或者是有外部网络访问时抓一下https://app-site-association.cdn-apple.com/的日志。苹果有自己的 AASA 缓存 CDN，验证频率和生效周期并不固定，所以刚配置完等几分钟再测是正常的。

2.3 AASA 文件的托管细节与常见返工点

AASA 文件虽然看着就几行 JSON，但托管时的坑足以让你排查一整天。

第一个问题是文件端口问题。AASA 必须通过 HTTPS 提供，同时该域名的 HTTPS 证书必须是受信任的 CA 签发的证书，自签名证书全家桶不行。有个团队遇到过这个问题：内网测试域名证书有效，但苹果的 AASA 拉取时用了公网 DNS 解析，域名解析出去的是内网代理的 IP，导致拉取不到文件，排查到最后发现是 DNS 分区域解析的锅。

第二个问题是文件放在哪一级路径。苹果官方要求放在域的“根目录”，不是子路径。如果你的域名是www.yourdomain.com，那文件路径是https://www.yourdomain.com/apple-app-site-association。有些人习惯把文件放/.well-known/下，那是其他生态（比如邮箱、TLS）的习惯，苹果并不认。

第三个问题是文件返回的 Content-Type。真实场景中我遇到 AASA 返回了文本内容但 Content-Type 是application/json而不是application/pkix-attr-cert或其他类型的情况，iOS 依然能正常处理，所以这个反而不是常规排障重点。真正的重点是：苹果 CDN 对 AASA 的抓取是带缓存的，更新文件后不会立即生效，官方没有明说缓存时长，实际观察下来短则十几分钟，长则几小时。所以发布新版本 App 要换 paths 时，最好提前把 AASA 文件改好，给苹果缓存留出更新时间。

第四个问题：多 App 共用一个域名时，paths 的配置会互相干扰。假如你有两个游戏共用一个域名，details 数组里各有各的 appID 和 paths，看起来没问题，但如果一个 appID 的 paths 写的是/open/*，另一个写的是/game/*，然后两个游戏又都装在同一台手机上，系统会先检查 App 的 Associated Domains 里有没有这个域名，有就继续读对应 appID 的匹配。只要两端都配对正确，就不会乱跳。

3. Unity 侧桥接：原生回调到 C# 的完整链路

iOS 原生侧配置好之后，真正的重头戏才刚开始：怎么让 Unity 的 C# 代码拿到 Deep Link 的 URL 和参数。这个环节的难度不在技术上，而在时序上——App 启动时 Unity 引擎还没完全 ready，Deep Link 就已经到了；热启动时 Unity 已经在跑，但 C# 侧可能还没注册好回调。要处理好这一层，得从原生代码和 C# 的生命周期对齐开始。

3.1 Objective-C 插件封装与 UnitySendMessage 的时序问题

iOS 原生侧用来接收 Deep Link 的入口分为两套：

接收到 URL Scheme 时会走 AppDelegate 的：

- (BOOL)application:(UIApplication *)application openURL:(NSURL *)url options:(NSDictionary<UIApplicationOpenURLOptionsKey,id> *)options;

接收到 Universal Links 时会走：

- (BOOL)application:(UIApplication *)application continueUserActivity:(NSUserActivity *)userActivity restorationHandler:(void (^)(NSArray<id<UIUserActivityRestoring>> * _Nullable))restorationHandler;

如果你是纯 Unity 项目，可以通过在 Xcode 工程里挂一个 AppDelegate 分类，或者用[UnityAppController]子类的方式拦截这两个方法。

拿到 URL 之后，原生层要立刻做两件事：第一，把 URL 字符串缓存到本地变量；第二，尝试通过UnitySendMessage发给 Unity 场景里的某个 GameObject。但问题就在第二件事上——冷启动时，Unity 场景还没有加载完或者 C# 侧方法没注册，UnitySendMessage发了也是白发。

业界普遍的做法是原生层先缓存，Unity C# 侧在某一个合适的时机主动向原生层拉取一次。举个例子，在 C# 侧写一个iOSDeepLinkManager，注册一个ApplicationDelegate或者用Unity runtime initializeOnLoad，等场景加载完了再调一个原生方法GetCachedDeepLink()，原生层把缓存的 URL 返回，同时清空缓存，确保一个链接只被消费一次。

还有个细节：UnitySendMessage要求接收消息的 GameObject 必须存在，而且方法名必须是公开的。如果时机不对，报的错会让你误以为原生层没调用成功。

3.2 C# 层参数解析、登记与分发

C# 侧接到的 raw URL 长这样：

https://yourdomain.com/open?scene=activity&actId=1001&channel=wechat&uid=888888

或者 URL Scheme 版：

yourgame://open?scene=activity&actId=1001&channel=wechat&uid=888888

接到 URL 以后，第一件事情是解析和规范化。我见过不少直接把整个 URL 丢给业务层的做法，后来都出了问题，因为业务层的字典解析逻辑对 URL 编码过的中文、特殊字符很敏感。正确做法是在统一的DeepLinkManager里完成：

public class DeepLinkManager : MonoBehaviour { private static DeepLinkManager _instance; public static DeepLinkManager Instance => _instance; private string _pendingUrl; private void Awake() { if (_instance != null && _instance != this) { Destroy(gameObject); return; } _instance = this; DontDestroyOnLoad(gameObject); #if UNITY_IOS && !UNITY_EDITOR IOSDeepLinkBridge.Init(OnDeepLinkReceived); string cachedUrl = IOSDeepLinkBridge.GetCachedDeepLink(); if (!string.IsNullOrEmpty(cachedUrl)) { OnDeepLinkReceived(cachedUrl); } #endif } public void OnDeepLinkReceived(string rawUrl) { if (string.IsNullOrEmpty(rawUrl)) return; // 统一解析为 DeepLinkData 对象 DeepLinkData data = ParseDeepLink(rawUrl); if (data == null) return; // 场景切换时缓存参数，避免丢失 _pendingUrl = rawUrl; // 分发到业务模块 Dispatch(data); } }

注意这里最关键的设计：用一个_pendingUrl把原始链接缓存下来，因为某些场景下（比如首帧时场景还没切换完）直接使用参数可能触发空引用。等 Loading 完成后再消费一次，参数就不会丢。

ParseDeepLink的核心就是把 URL 拆成 scheme、host、path、query 四部分。Unity 自带的Uri类虽然可以解析，但在 iOS 上它有个小毛病：如果 URL 里的 host 带端口号，有时会解析异常。我的习惯是先用字符串简单切分 query 部分，再用WWW.UnEscapeURL做 URL 解码，这样最稳。

3.3 冷启动与热启动两条路径的统一封装

我在这里展开一下冷启动和热启动的时序差异，因为这是最容易让开发者“调半天都不知道错在哪”的地方。

冷启动的定义是：App 进程不存在，用户点击链接，系统拉起 App 进程。这个时候 AppDelegate 的didFinishLaunchingWithOptions里其实已经可以拿到launchOptions里的 URL，但 Unity 引擎正在启动、场景还没开始加载，C# 侧的 MonoBehaviour 还没 Awake。如果你在didFinishLaunchingWithOptions里直接UnitySendMessage，大概率失败。

所以冷启动的安全路径是：原生层在didFinishLaunchingWithOptions里保存launchOptions[UIApplicationLaunchOptionsURLKey]或者通过continueUserActivity拿到 Universal Links 的网页 URL，把这个 URL 存到一个NSString静态变量里。同时注册一个原生方法，比如：

const char* _GetCachedDeepLink() { if (cachedDeepLink != nil) { const char* result = [cachedDeepLink UTF8String]; cachedDeepLink = nil; return result; } return ""; }

C# 侧在 MonoBehaviour Awake 里调用这个原生方法，取回缓存，然后像处理普通参数一样走Dispatch。这样冷启动就完成了。

热启动的路径简单得多：App 已经在前台或后台，Unity 场景就绪，用户点链接时系统会把 URL 快传给仍在运行的 App。原生层收到后立刻UnitySendMessage，C# 侧立刻消费。这个路径几乎没有时序问题，只要 GameObject 存在即可。

统一封装后，C# 侧不管冷热，都走OnDeepLinkReceived一个入口，业务层不用关心背后的时序列。整个设计的核心思想就是：冷启动靠缓存和主动拉取，热启动靠消息推送，两条腿最终汇合到一个 C# 解析函数。

4. Deep Link 参数投递全链路解析与实战

前面把两端的配置都打通了，这一节重点落到“参数投递”本身。参数是从一个 URL 字符串变成 C# 业务对象，再分发到具体模块的过程。很多团队卡在这一步的细节上，比如参数缺失、中文乱码、有参数但业务模块拿不到，这些大多是因为没有一套完整的解析与约定规范。

4.1 从 URL 到结构化参数的还原

一个标准的 Deep Link 数据结构，我建议这样定义：

public class DeepLinkData { public string scene; // 要跳转的场景：activity、recharge、room... public string channel; // 来源渠道：wechat、shortmsg、ad... public string uid; // 可选的业务 ID public string actId; // 活动 ID public string extra; // 兜底扩展参数 }

解析函数的职责不是简单把 query 拆成字典，而是要处理三个层面的问题：URL 编码、参数规整、场景映射。URL 编码要处理的是%E4%B8%AD%E6%96%87这类中文参数；参数规整要处理的是空值、默认值、类型转换；场景映射则是把scene这个字符串映射成游戏里的具体入口枚举。

我在项目里用过一个稍微有门槛但实用的方式：把 query 参数拆成字典后，做一个白名单过滤，只留下scene、channel、actId这几个约定好的 key，其余参数作为extra原样拼回字符串，由具体业务模块自己解析。这样既统一了主链路，又留出了扩展空间，不会因为加了几个投放参数就改一次基类。

4.2 归因参数与业务参数的分离处理

手游 Deep Link 里，有一个很容易被 Unity 开发者忽略的角色：第三方归因 SDK。买量平台（比如 AppsFlyer、Adjust、热力引擎等）一般都会要求在客户端集成它们的 SDK，由 SDK 自己接收 Deep Link 并上报。如果 C# 层也同时解析同一份 URL 并参与业务跳转，就可能出现参数冲突。

真实案例：广告点击链接到了 App，归因 SDK 先收到 URL，识别出点击 ID，随后正常跳转页面；但 C# 层如果也拿到了 URL，把广告参数里的af_sub1当成业务参数派发，可能会导致页面跳转异常。所以实践中一般会约定：归因参数和业务参数分区管理。业务参数放在业务约定的 query key 里（比如scene、actId），归因参数放在另一个 key（比如af_sub2），C# 主解析只认业务 key，归因参数直接透传给 SDK 回调，不进入业务字典。

这样做的好处是很直观的：投放同事改链接、加追踪参数，不会影响游戏内的业务跳转；游戏业务侧的代码也不用关心 SDK 的内部逻辑。分工清晰，排查问题也方便。

4.3 完整投递链路的验证与 log 设计

验证整条链路是否打通，不能光靠玩家报告“点了没反应”。我自己在实践中会准备一套完整的验证手段：

第一步，用 Xcode 跑真机，在 AppDelegate 收到 Deep Link 的入口打印日志，确认原生层收到的是完整原始 URL，不被系统截断。这一步能筛掉“AASA 没生效”这类基础设施问题。

第二步，在 C# 侧的OnDeepLinkReceived里打日志，确认 URL 已经跨过桥接层，而且参数没丢。很多藏得深的坑（比如UnitySendMessage被调用时 GameObject 被销毁）在这一步就暴露了。

第三步，真机上用 Safari 直接访问完整的 Universal Links 地址。这里有个技巧：Safari 地址栏输入链接后直接回车，系统会优先尝试 Universal Links 唤起。如果没唤起而是打开了网页，说明 Associated Domains 或者 AASA 校验有异常。此时可以再用 URL Scheme 手动调一次，对比两条链路的差异。

日志内容最好统一 JSON 格式，方便以后接入日志平台。我项目里加了一个DLinkLog(string tag, string msg)的辅助方法，同时输出到 Xcode 控制台和 Unity Console，至少在联调阶段能少折磨自己几个小时。

5. 常见问题与排查技巧实录

Deep Link 的坑，一半在 iOS 系统策略，一半在自己写的代码里。我把踩过的、同事踩过的、在社区里看到的高频问题整理成速查表，你在实际联调时可以对着排查。

5.1 高频问题速查表

5.2 真机调试时的日志与断点技巧

Deep Link 联调必须用真机，模拟器上 Universal Links 的表现和真机有差异，尤其涉及 AASA 抓取时，模拟器往往不按真实链路走。

原生层调试时，断点打在continueUserActivity和openURL里是最直观的。但有些时候断点太频繁（比如每次切后台都会触发），可以将日志输出到统一文件，真机端可以在 Xcode 的 Device Log 里直接查看。我的做法是自定义一个DLog宏，在 Debug 模式输出到 NSLog 的同时，也通过 PostProcessBuild 挂一个DLog导出接口，这样 C# 侧调用原生接口时就能直接把原生日志输出到 Unity Console，实现站内统一排查。

C# 侧调试时，在OnDeepLinkReceived入口和Dispatch出口各打印一次，就能定位是“根本没收到”还是“收到但分发失败”。

5.3 几个容易忽略的细节

第一，Universal Links 的域名必须和设备上配置的 Associated Domains 完全匹配。有人配了applinks:yourdomain.com，但测试链接是用https://www.yourdomain.com，域名不一致，系统不会唤起。AASA 文件里paths匹配的是路径前缀，域名不带 www 和非带 www 在 AASA 内部处理时可以视为两个域，官方文档表述比较含糊，实战经验是用哪个域名做推广，就把它完整配到 Associated Domains 和 AASA 里。

第二，AASA 的paths匹配是“最长匹配优先”，而且支持NOT语法，比如：

"paths": [ "NOT /open/forbidden/*", "/open/*" ]

如果想要某些路径不唤起 App 而是进 H5，用NOT更简单。我接运营需求时经常会用到这个语法。

第三，冷启动路径下，如果 App 是通过 Universal Links 唤起，且是第一次安装启动，系统可能需要用户先授权或先进入一次 App、再点链接才能稳定唤起。这个行为比比皆是——新装用户首次点击链接，系统会提示“在 App 中打开吗”，这个交互流程如果有产品环节介入，要在用户引导说明里设计进去。

6. 无法回避的兼容性问题与最后的心得

接 Deep Link 的过程，本质上是和 iOS 的系统策略、苹果的 CDN 缓存、第三方 WebView 的行为博弈。这部分我把兼容性问题单独拎出来说，因为它决定了你的方案能在多长时间内不返工。

6.1 第三方浏览器与 WebView 的兼容策略

iOS 上除 Safari 外的第三方浏览器（微信、抖音、QQ 内置 WebView）对 Universal Links 的支持并不完美。部分浏览器会拦截 Universal Links 的网络请求，导致点击后只打开网页不唤起 App。

针对第三方浏览器的兼容，业内通常有三种策略：

一是提供 URL Scheme 作为第二跳方案。比如在 H5 落地页检测到 App 未通过 Universal Links 唤起时，写一段 JS 触发隐藏的 iframe 跳转到yourgame://...，同时播放一段引导“点击右上角在 Safari 中打开”。这个方案不完美，但实测能覆盖一部分用户场景。

二是使用开放者服务商的 App Link 方案。有些第三方服务（国内常用的是各种深度链接服务）会做一个 H5 中间页，帮你探测环境后分发到 Universal Links 或 URL Scheme，同时处理未安装场景的下载跳转。接这类 SDK 能省不少事，但需要评估第三方 SDK 的体积、隐私合规和是否有额外费用。

三是从产品设计层面降低唤起门槛。比如短信、Push 里的链接，直接不依赖“自动唤起”，改成“点击后先显示一个确认页，用户点按钮再唤起”。这个方式用户体验上多了个步骤，但唤起成功率是最高的。

6.2 参数安全与隐私合规

Deep Link 参数里经常带uid、channel、actId这些信息，虽然本身不一定是隐私数据，但如果在链路里被截获或记录，仍然有合规风险。我的原则是：

• 链接里的用户标识尽量用不可逆的编码串，不要直接明文传手机号或身份证号；
• 链接推广出去后，整个 URL 是会暴露在浏览器历史、归因平台、第三方日志里的，敏感字段宁可少传；
• C# 侧拿到参数后，如果需要上报，要先经过服务端校验再入库，不要把客户端传来的参数直接当信任输入。

6.3 最后一句话

整个 Deep Link 方案的工程实现到这一步已经算是闭环了。回头看，真正坑人的不是技术本身，而是“时序”和“约定”。时序好解决，只要记住“原生缓存、C# 主动拉取、热启动推送”三条原则；约定比较难，需要团队里运营、投放、客户端三方统一参数命名和跳转规则。如果让我给第一次接这个需求的团队一句建议：先把参数规则定死，再去碰 iOS 配置。规则一旦定得随意，后面每一次加链接都是给自己埋雷。

我在实际项目里规划过一套小模板，所有 Deep Link 的业务参数 key 都集中在DeepLinkConst.cs里：

public static class DeepLinkConst { public const string SCENE = "scene"; public const string ACT_ID = "actId"; public const string CHANNEL = "channel"; public const string UID = "uid"; public const string EXTRA = "extra"; }

这套常量文件让运营、客户端、服务端各自对照字段，从源头避免了“同一个参数叫了三种名字”的问题。你接到类似需求时，无论从哪一步开始做，都可以先把这个文件建起来，后面的日子会好过得多。