1. 项目概述为什么设备ID是个“坑”干了这么多年Unity开发但凡项目涉及到用户识别、数据统计、防作弊或者付费验证设备IDDevice Identifier都是一个绕不开的话题。很多开发者尤其是刚入行的朋友第一个想到的就是SystemInfo.deviceUniqueIdentifier。Unity官方API文档写得明明白白“唯一设备标识符。保证对于每个设备都是唯一的只读。” 这话听起来多让人安心直接拿来用不就完了但现实往往是当你把游戏发布出去看着后台数据里一堆重复、无效或者突然变化的设备ID时才会一拍大腿“这玩意儿怎么不靠谱啊”这个项目标题——“Unity SystemInfo.deviceUniqueIdentifier真的可靠吗实测对比5种设备ID方案”——就精准地戳中了这个痛点。它不是一个简单的API使用教程而是一次针对“可靠性”这个核心命题的深度实测与横向对比。在移动互联网时代设备ID是连接虚拟用户与物理设备的桥梁它的稳定性直接关系到用户画像的准确性、反作弊系统的有效性、广告归因的精确度乃至商业收入的真实性。一个不可靠的设备ID轻则导致数据统计失真重则可能让整个基于设备的业务逻辑如设备绑定、防刷单形同虚设。所以这篇文章的目的就是带你彻底搞懂Unity中获取设备ID的“水”有多深。我会结合自己踩过的无数个坑不仅告诉你SystemInfo.deviceUniqueIdentifier在iOS、Android、Windows等各个平台下的底层实现和潜在问题还会拿出另外4种常见的替代或补充方案进行一场实打实的对比测试。你会看到在不同系统版本、不同设备状态如恢复出厂设置、系统升级、不同发布渠道如Google Play正式包与本地调试包下这些ID的表现如何。最终我们不是要找到一个“银弹”而是要建立一个清晰的认知在什么场景下该选择哪种方案或者如何组合多种方案来构建一个相对更健壮的设备识别体系。无论你是负责游戏运营的数据分析师还是正在为项目设计账号体系的客户端程序员这篇文章里的实测数据和经验总结都能帮你避开那些教科书里不会写的“暗礁”。2. 核心需求解析我们需要什么样的设备ID在动手测试之前我们必须先明确目标一个理想的设备ID应该具备哪些特性这决定了我们评价各种方案优劣的标准。根据我多年的项目经验主要从以下几个维度来考量2.1 唯一性Uniqueness这是最基本的要求即一台设备在合理的生命周期内只对应一个ID且不同设备的ID不应重复。但“生命周期”是关键用户恢复出厂设置后是否应该被视为一台“新设备”从业务角度有时需要区分有时则希望关联。2.2 持久性PersistenceID在设备上的存活时间。理想情况是“一次生成终身不变”。但现实很骨感系统升级、应用卸载重装、甚至用户主动重置广告标识符IDFA/AAID都会导致ID变化。我们需要评估各种ID对这些事件的抵抗能力。2.3 可重置性Resettability这与持久性相对。从用户隐私角度部分ID如广告标识符允许用户重置这是法规要求如GDPR、CCPA。从开发者角度这带来了不确定性但我们必须尊重并适应。2.4 可访问性Accessibility获取该ID是否需要特殊权限如Android的READ_PHONE_STATE是否受系统版本限制如Android 10对设备标识符的访问限制是否需要依赖特定服务如Google Play服务这直接关系到方案的普适性和上架合规性。2.5 跨平台一致性Cross-platform Consistency对于Unity这样的跨平台引擎我们当然希望一套代码能在iOS、Android、PC等平台上获取到语义相似的ID即使底层实现不同。2.6 防篡改性Tamper Resistance在反作弊场景下ID被伪造或篡改的难度有多大例如通过修改系统文件、使用模拟器或特定工具能否轻易改变ID没有任何一个方案能在所有维度都得满分。SystemInfo.deviceUniqueIdentifier试图在唯一性和跨平台性上做一个封装但它内部的黑盒实现恰恰是风险的来源。接下来我们就先把它拆开来看。3. 方案一深度剖析SystemInfo.deviceUniqueIdentifier的黑盒与风险Unity的SystemInfo.deviceUniqueIdentifier就像一个封装好的“万能”接口用起来简单但理解其内部机制至关重要否则就是盲人骑瞎马。3.1 各平台底层实现揭秘根据Unity官方脚本API文档结合我查阅的源码和实测它的行为如下iOS:iOS 7之前返回设备Wi-Fi或蓝牙MAC地址的哈希值。MAC地址是硬件标识理论上是唯一的但苹果从iOS 7开始出于隐私考虑禁止应用访问设备的MAC地址。所以对于现代应用这个路径已基本失效。iOS 7及之后优先返回UIDevice的identifierForVendor(IDFV)。如果获取失败极少数情况则回退到ASIdentifierManager的advertisingIdentifier(IDFA)。这里有个关键点IDFV对于同一个“供应商”即由同一开发者账号签名的所有App下的应用是相同的。如果用户卸载了你开发商的所有AppIDFV可能会变。而IDFA是用于广告追踪的用户可以随时在系统设置中重置它。Android:始终返回ANDROID_ID即Settings.Secure.ANDROID_ID的MD5哈希值。这是一个64位的十六进制字符串。但是这里有巨坑签名依赖自Android 8.0 (API 26) 起ANDROID_ID的值与应用签名密钥绑定。这意味着同一个设备上用不同签名密钥安装的同一个应用获取到的ANDROID_ID是不同的。调试与发布差异在开发时如果你使用调试密钥debug keystore签名APK得到的ANDROID_ID(我们称为A) 与使用发布密钥upload keystore签名后从Google Play下载的APK得到的ANDROID_ID(称为B) 是不同的。A和B之间没有关联。工厂重置与系统升级在主流设备上恢复出厂设置会改变ANDROID_ID。某些系统大版本升级也可能导致其变化。Windows (UWP/应用商店应用):首选尝试获取AdvertisingManager::AdvertisingId广告ID。如果用户禁用了“允许应用使用广告ID”的隐私设置则回退到HardwareIdentification::GetPackageSpecificToken().Id。这个Token是基于硬件信息的但也是应用特定的。Windows/Mac/Linux (独立平台):通过查询一系列系统硬件信息如主板序列号、BIOS序列号、CPU ID、硬盘序列号等将它们拼接后计算哈希值。问题在于这些信息的可用性和可靠性因设备而异。虚拟机、组装机或某些品牌机可能返回空值或通用值导致生成的ID不稳定或重复。3.2 实测中的典型“翻车”场景在我的实测中遇到了以下具体问题Android模拟器不同模拟器实例甚至同一镜像的不同副本可能产生相同的ANDROID_ID导致deviceUniqueIdentifier重复。这对于依赖设备唯一性进行封禁的反作弊系统是致命的。Android本地调试包 vs Google Play正式包如前所述因为签名密钥不同这两个包获取的ID完全不同。如果你在开发阶段用本地ID建立了测试数据上线后会发现完全对不上后台统计会误判为大量新设备。iOS还原设备与重置广告标识符如果用户抹掉所有内容和设置IDFV会改变。如果用户仅在设置中重置广告追踪重置IDFA而你的App恰好回退到使用IDFA那么设备ID也会变。PC平台硬件变更用户更换了硬盘或主板对于独立平台构建的游戏其deviceUniqueIdentifier很可能改变导致游戏将同一台电脑识别为两台不同的设备。注意SystemInfo.unsupportedIdentifier是一个常量字符串当Unity无法在某个平台上获取任何有效的硬件或系统标识符时就会返回这个值。虽然罕见但在一些非常规或高度定制的设备上可能出现。3.3 适用场景与规避建议尽管有诸多问题SystemInfo.deviceUniqueIdentifier并非一无是处。它适合用于对持久性要求不高、更偏向匿名统计的场景例如统计单次会话内的崩溃报告关联设备日志。在不涉及核心资产和交易的休闲游戏中进行简单的DAU/MAU统计。规避建议绝对不要将其用于核心业务逻辑如用户账号绑定、支付凭证验证、永久性封禁。在Android平台务必意识到调试ID和发布ID的差异后台数据分析时要能区分来源。在iOS平台明确其可能因卸载应用或重置广告标识符而改变。4. 方案二至方案五横向对比与实测认识到SystemInfo.deviceUniqueIdentifier的局限性后我们必须寻找其他方案。下面我将对比另外四种常见方案并分享实测数据。4.1 方案二Android ID (Settings.Secure.ANDROID_ID) 的直接使用既然Unity的Android实现就是基于这个我们直接获取它可以获得更原始的数据和控制力。原理通过Android Java接口调用Settings.Secure.getString(context.getContentResolver(), Settings.Secure.ANDROID_ID)。实测表现与SystemInfo.deviceUniqueIdentifier在Android上的问题完全一致签名依赖、恢复出厂重置。直接获取的是16进制字符串比MD5哈希更原始。优点无需额外权限在大多数Android版本上获取简单。缺点继承了所有ANDROID_ID的固有问题。在Android 10及以上作用域进一步受限。适用场景作为设备ID的组成部分之一与其他ID组合使用。单独使用风险高。4.2 方案三iOS Vendor ID (IDFV) 与 Advertising ID (IDFA)在iOS端我们通常需要更精细地控制使用哪种标识符。IDFV (identifierForVendor):原理同一供应商开发者应用间共享。卸载所有该供应商应用后值可能变。实测在大多数情况下稳定是识别“设备开发者”组合的较好选择。适用于分析用户在你旗下多个应用中的行为。获取通过UIDevice.current.identifierForVendor?.uuidString。IDFA (advertisingIdentifier):原理用于广告追踪用户可在“设置-隐私-跟踪”中重置或关闭。实测用户重置后立即变化。从iOS 14.5开始需要主动请求用户授权ATT框架才能获取否则返回全零。获取通过ASIdentifierManager.shared().advertisingIdentifier.uuidString。必须在Info.plist中添加NSUserTrackingUsageDescription描述。对比特性IDFVIDFA重置条件卸载同一供应商所有App用户手动在设置中重置跨应用同一供应商下共享所有应用共享如果授权隐私要求无需额外授权需要ATT授权iOS 14.5用途分析、非货币化识别广告归因、跨应用追踪稳定性较高低用户可控4.3 方案四使用第三方平台SDK提供的ID许多大型第三方服务如Firebase Analytics、AppsFlyer、Adjust会生成自己的持久性设备ID。原理SDK首次安装时生成一个UUID并将其持久化存储在本地。即使用户卸载重装只要SDK的持久化存储逻辑能恢复这个ID它就能保持不变。实测以Firebase为例Firebase Analytics 的FirebaseAnalytics.Instance.AppInstanceId在应用卸载重装后通常会保持不变因为它使用了Android的SharedPreferences备份机制或iOS的钥匙串等技术来尝试恢复。但是如果用户清除了应用数据或者在新设备上恢复备份且备份不包含此数据ID仍会改变。优点通常比系统ID更持久对抗卸载重装。与第三方分析平台无缝集成。缺点绑定于特定SDK切换或移除SDK会导致ID体系断裂。不同第三方SDK的ID不同无法统一。仍然无法100%保证永久不变。4.4 方案五自定义生成与持久化GUID/UUID这是最基础、也是最可控的方案。原理应用首次启动时在本地生成一个随机的UUID例如System.Guid.NewGuid().ToString()并将其保存到持久化存储中如PlayerPrefs、文件、甚至钥匙串/Keystore。以后每次启动都读取这个值。实测卸载即失效用户卸载应用后本地存储被清除重新安装会生成全新的UUID。跨设备同步如果结合云存档或账号系统可以将此UUID上传并与用户账号绑定实现跨设备标识。优点完全自主可控逻辑简单。无需任何系统权限。在应用生命周期内绝对稳定除非用户清理数据。缺点无法识别设备本身。同一台设备卸载重装后就是“新用户”。无法对抗同一设备上安装多个副本如双开应用。进阶技巧可以将生成的UUID写入到多个存储位置如PlayerPrefs和一个独立文件来增加恢复几率。在Android上可以尝试将UUID写入到External存储的特定目录需要权限但这不是好做法且Android 11后作用域受限。更佳实践将此自定义UUID与一个或多个系统ID如Android ID的哈希组合生成一个复合ID。即使系统ID因恢复出厂设置而改变只要自定义UUID还在就能部分维持连续性。5. 五种方案实测数据对比与场景选型指南我设计了一个测试流程在一台Android手机小米12 Android 13、一台iPhoneiPhone 13 iOS 17和一台Windows PC上模拟了以下场景并记录了各方案ID的变化情况首次安装启动。完全卸载应用后重新安装。Android使用调试密钥安装 vs 使用发布密钥安装。iOS重置广告标识符。Android恢复出厂设置通过模拟器测试。以下是简化后的对比结果表方案平台唯一性持久性 (抗卸载)持久性 (抗恢复出厂)隐私合规性获取难度备注SysInfo.dui跨平台中低低中极低黑盒实现平台差异大调试/发布包ID不同是巨坑。Android IDAndroid中低低高低同SysInfo.dui(Android)但更透明。Android 10有限制。iOS IDFViOS高中高高低供应商维度稳定卸载所有同供应商应用后变。iOS IDFAiOS高极低高低(需授权)中用户可重置ATT框架下获取困难。用于广告。第三方SDK ID依赖SDK高高中中中依赖SDK实现卸载重装可能恢复清数据则丢。自定义GUID跨平台高低低高低卸载即丢完全依赖本地存储。可控性强。5.1 分场景选型建议没有最好的只有最合适的。根据你的核心需求来选择场景一匿名数据统计与分析如DAU、崩溃报告推荐SystemInfo.deviceUniqueIdentifier或自定义GUID。理由对持久性要求不高需要简单快捷。自定义GUID更可控但需接受卸载即丢。SysInfo.dui可以但要清楚其平台差异。场景二用户账号体系与设备绑定如一个账号最多绑定3台设备推荐复合ID策略。例如哈希(自定义GUID 部分稳定系统ID)。理由单一ID不可靠。自定义GUID保证应用内的连续性加入系统ID如Android ID的哈希可以增加跨设备识别的难度即使GUID丢失系统ID可能还在。当用户在新设备登录时可以用系统ID尝试关联旧设备需在服务器端实现匹配逻辑。场景三反作弊与永久封禁推荐多因子采集 服务器端风险决策。理由任何客户端ID都可被篡改越狱/ROOT后。不能依赖单一ID。应采集多个设备特征如SystemInfo中的设备型号、显卡名称、处理器数量等、网络IP注意隐私、行为模式等在服务器端构建设备指纹。即使一个ID变了其他特征组合仍能进行高概率识别。SystemInfo.deviceUniqueIdentifier可以作为指纹的一个组成部分但权重不能给太高。场景四广告归因与跨应用追踪推荐iOS使用IDFA需ATT授权Android使用Google Advertising ID (AAID)。理由这是移动广告生态的标准做法。AAID和IDFA就是为此设计的虽然用户可重置。Unity没有直接提供AAID的接口需要通过Android原生代码获取。场景五依赖第三方生态如Firebase数据分析推荐直接使用该SDK提供的Instance ID。理由保证与该平台内部数据的一致性。如果你主要的数据看板都在Firebase Console那么使用Firebase自己的ID是最省事、数据最对齐的。6. 实战构建一个混合增强型设备标识符方案理论说了这么多我们来点实际的。我将分享一个在中等规模项目中验证过的、相对健壮的混合ID生成方案。这个方案的核心思想是分层采集、本地生成、服务器校验。6.1 客户端采集层在应用启动时尝试从多个来源采集标识符按优先级和稳定性分级// 伪代码示意逻辑 public class DeviceIdentifierManager { public string GetCompositeDeviceId() { // 层级1最持久、最可靠的如果可用 string idCustom LoadCustomUUID(); // 从本地持久化存储读取自定义UUID if (string.IsNullOrEmpty(idCustom)) { idCustom GenerateAndSaveCustomUUID(); // 生成并保存 } // 层级2系统级ID不稳定但可作为补充 string idSystem SystemInfo.deviceUniqueIdentifier; // 层级3平台特定ID更精细的控制 string idPlatformSpecific GetPlatformSpecificId(); // 例如在Android上可以尝试获取ANDROID_ID和AAID在iOS获取IDFV // 层级4设备特征用于指纹不直接作为ID string deviceFingerprint GenerateDeviceFingerprint(); // 可以包含设备型号、操作系统版本、屏幕分辨率、CPU核心数等SystemInfo信息 // 组合策略示例将相对稳定的部分进行哈希 string compositeKey ${idCustom}_{GetStablePart(idSystem)}_{GetStablePart(idPlatformSpecific)}; string compositeHash CalculateHash(compositeKey); // 例如MD5或SHA256 // 将 compositeHash, idCustom, deviceFingerprint 一起发送给服务器 return compositeHash; } private string GetPlatformSpecificId() { #if UNITY_ANDROID !UNITY_EDITOR // 通过AndroidJNI调用获取ANDROID_ID // 尝试获取Google Advertising ID (AAID) - 需要Google Play服务 #elif UNITY_IOS !UNITY_EDITOR // 通过iOS原生插件调用获取IDFV #endif return platform_specific_id; } }6.2 服务器端校验与关联层客户端上传的compositeHash和deviceFingerprint不能直接信任。首次上报当服务器收到一个从未见过的compositeHash时将其与deviceFingerprint一起存入数据库标记为“设备记录A”。后续上报如果compositeHash匹配到现有记录则认为是同一设备。如果compositeHash不匹配但deviceFingerprint与某个已有记录高度相似例如80%的特征匹配则服务器可以判断这可能是一台设备因系统升级、恢复出厂设置导致ID变化。此时可以进行“疑似设备关联”并可能将新旧compositeHash在逻辑上关联起来。如果compositeHash和deviceFingerprint都全新则视为新设备。风险控制服务器可以维护一个设备指纹-行为黑名单。如果一个作弊用户的设备指纹被标记即使他更换了ID当其新ID对应的指纹与黑名单库匹配时仍然可以触发风控。6.3 本地存储策略自定义UUID的存储至关重要目标是尽可能在卸载重装后恢复。iOS使用钥匙串Keychain。钥匙串中的数据不会因应用卸载而被清除除非用户手动抹掉整个设备。这是iOS上实现持久化ID的最佳实践。你需要编写一个iOS原生插件或使用现有的Unity插件如Unity.iOS.Keychain来访问钥匙串。Android目标API 29可以考虑使用SharedPreferences并配置为自动备份android:allowBackup”true”。当用户在新设备上恢复备份时SharedPreferences数据可能被恢复。但这并不可靠。更佳实践使用AndroidKeystore系统存储一个加密的密钥或UUID。AndroidKeystore是硬件支持的密钥存储系统其内容与应用绑定且在某些情况下能抵抗卸载。实现起来更复杂但安全性更高。折中方案将UUID同时写入SharedPreferences和内部存储的一个文件。增加数据恢复的概率。重要提示无论采用何种本地存储方案都必须假设数据可能丢失。你的业务逻辑必须能处理“设备ID重置”的情况例如将其视为一次干净的“新设备”登录并提供合理的引导流程。7. 常见问题与排查技巧实录在实际开发和线上运维中我遇到了无数关于设备ID的“灵异事件”。这里总结几个最典型的以及我的排查思路。7.1 问题Android后台数据显示正式上线后突然出现海量“新设备”但DAU没涨。排查首先怀疑SystemInfo.deviceUniqueIdentifier的调试/发布签名问题。检查上报ID的格式或来源标记。确认测试阶段使用的是调试包而线上是发布包。这两个包的ID本来就不一样服务器自然认为是新设备。检查服务器去重逻辑。是否只是简单地将收到的设备ID直接插入“设备表”应该先查询是否存在。检查客户端网络重试机制。是否因为网络不稳定导致同一个设备在短时间内多次发送“首次启动”请求需要在客户端本地标记首次上报状态或在服务器端对短时间内同一ID的重复请求做去重。解决短期在服务器后台根据设备其他特征如IP、User-Agent、设备型号对这批“新设备”数据进行聚类分析很可能发现它们都来自相似的测试环境特征可以手动过滤或打标签。长期建立两套ID体系。一套用于内部测试基于调试签名一套用于生产环境。或者在服务器端根据请求包中的版本号、渠道号等信息能够识别出调试数据并路由到测试数据库。7.2 问题有用户反馈“账号被踢出”或“设备绑定满了”但他坚称只在一台设备上登录。排查获取该用户的设备ID历史记录。查看其账号下关联的设备ID是否频繁变化。分析变化规律。是否在系统更新尤其是Android大版本升级、应用商店更新应用后发生变化这指向了ANDROID_ID在特定条件下的改变。用户是否使用了“双开”、“应用分身”功能这些功能可能会虚拟化或修改设备环境导致每次打开都生成不同的ID。用户是否在模拟器上玩游戏模拟器的设备信息可能是重复或变化的。解决客服层面引导用户检查是否开启了双开功能并解释设备ID可能因系统更新而变化的可能性。技术层面优化设备绑定逻辑。不要简单地“一个账号绑定一个设备ID”而是改为“一个账号绑定一个设备令牌Token”该令牌可以定期刷新。或者采用更宽松的绑定策略允许用户在一定时间内在少数几台设备上切换并结合短信验证等二次确认手段。数据层面在数据库中将用户与设备ID的关系设计为“一对多”的历史记录而不是“一对一”的当前绑定。这样便于追踪设备变化历史和进行问题诊断。7.3 问题iOS版本更新后部分老用户的游戏数据“丢失”了其实是服务器认不出设备了。排查重点检查IDFV的获取逻辑。是否在某个版本更新中错误地修改了Bundle Identifier的团队前缀IDFV是基于“供应商”的而供应商由团队ID和Bundle ID的前缀部分决定。如果这部分变了IDFV就会变。检查是否在更新中引入了新的获取ID的插件或代码错误地优先使用了IDFA而用户恰好重置了广告标识符。解决确保App的Bundle Identifier中用于定义“供应商”的部分通常是团队ID永不改变。在版本更新时如果必须改变Bundle ID要有数据迁移方案。例如在旧版本的最后一次运行中将旧的设备ID或自定义UUID上传到服务器并与用户账号关联。新版本首次启动时尝试从服务器拉取关联的ID。7.4 快速自查清单当你遇到设备ID相关问题时可以按以下顺序排查现象可能原因检查点所有Android设备ID重复使用了模拟器或ANDROID_ID在某些定制ROM上返回通用值。1. 测试真机。2. 检查SystemInfo.deviceModel是否包含“sdk”或“emulator”等模拟器关键词。单个用户设备ID频繁变1. 用户频繁卸载重装自定义UUID丢失。2. 用户系统/应用分身。3. Android恢复出厂或大版本更新。1. 分析ID变化时间点与版本更新日志的关联。2. 检查上报数据中是否包含分身环境信息如有。3. 查看用户设备型号和系统版本是否在变化。iOS用户ID变化1. 用户重置广告标识符如果用了IDFA。2. 用户卸载了同一开发者的所有AppIDFV变。3. Bundle ID的供应商部分被更改。1. 确认使用的是IDFV还是IDFA。2. 检查App的Bundle Identifier历史。调试与正式环境ID不同Android签名密钥不同导致ANDROID_ID不同。对比调试APK和发布APK的签名证书指纹。PC平台ID不稳定硬件信息查询失败如虚拟机或用户更换了关键硬件。检查SystemInfo.deviceUniqueIdentifier是否返回unsupportedIdentifier或对比更换硬件前后的系统报告。设备ID的可靠性是一个在“用户体验”、“业务需求”和“隐私法规”之间走钢丝的平衡艺术。经过对SystemInfo.deviceUniqueIdentifier及其他四种方案的实测与剖析我们可以清晰地看到没有任何一个方案是完美的银弹。Unity提供的这个接口其最大的价值在于跨平台的便捷性但它将不同平台底层复杂且脆弱的标识逻辑封装成一个看似简单的属性这本身就是一个巨大的风险点。对于严肃的商业项目我的核心建议是放弃寻找一个“永远不变”的设备ID的幻想转而设计一个能够容忍ID变化的、多层次的识别体系。这个体系应该包含一个由你掌控的自定义UUID作为应用内标识的基石并尽最大努力如使用钥匙串、Keystore使其持久化。选择性采集系统级ID如Android ID、IDFV作为辅助参考和关联线索但绝不作为唯一依据。一套设备指纹机制收集一组相对稳定的软硬件特征如屏幕尺寸、CPU架构、显卡名称等在服务器端用于相似度匹配和风险控制。尽早引入用户账号体系。无论是简单的游客ID转正还是第三方社交账号登录将身份标识从设备转移到账号是解决设备ID不可靠问题的根本之道。设备ID应作为账号安全的一个辅助验证维度而非身份本身。最后在测试阶段务必在真机上用发布版本的签名模拟卸载重装、系统更新等关键场景来验证你的设备识别逻辑是否健壮。数据后台也要做好设备ID变化轨迹的日志记录这样当问题真正发生时你才有据可查而不是凭空猜测。