KYC 的全称是 Know Your Customer也就是“了解你的客户”。在加密货币交易所注册、领取区块链空投、或者使用钱包内置的身份服务时几乎都会遇到这个词。很多人把 KYC 当成“上传证件照片的页面”但它在业务和法律上承担的任务远比一个上传框复杂。KYC 既是一套身份识别流程也是金融、Web3 和数字资产平台必须面对的合规底线。真正值得关注的变化发生在区块链语境里KYC 正在从“把身份证复印件交给平台”变成“用户自己持有凭证、按需出示、只暴露必要信息”。这就是去中心化 KYC 的核心思路。这篇文章会先讲清楚 KYC 到底是什么再拆解去中心化 KYC 的技术组成然后说明它对普通人有哪些实际作用最后给出最小可理解流程、常见误区和一份可执行清单。1. KYC 不是“上传身份证”这么简单先拆开传统流程1.1 KYC 的业务含义和法律含义KYC 在金融行业里的最初目的是让机构在建立业务关系之前确认客户是谁。银行开户、证券开户、支付账户注册都会要求提供姓名、证件号码、住址、职业等信息。这个动作不只是为了防诈骗还关系到反洗钱、反恐怖融资、税务合规和跨境资金监管。把 KYC 放到数字资产和区块链项目里语境也类似。加密货币交易所要上币、要开通法币出入金、要防止洗钱往往就需要知道链上地址背后的人是谁。稳定币发行方在赎回环节也要验证用户身份NFT 平台在发大型活动奖励时也要确认“同一个用户不是批量注册的小号”。所以 KYC 不是某个平台的创新而是业务合规链条里绕不开的一环。这里要澄清一个常见误解KYC 不等于把所有证件信息都交给平台保存。KYC 的最终目标是“平台能够在必要时候验证你是一个真实、未被封禁、与历史风险记录可以被关联起来的自然人”。至于用什么技术方式完成验证传统方案和去中心化方案选择的是完全不同的两条路。1.2 传统中心化 KYC 的典型链路传统 KYC 流程通常可以拆成四个阶段身份信息采集用户填写姓名、出生日期、国籍、居住地址并上传身份证或护照照片。证件真实性校验平台调用第三方 OCR 服务读取证件上的字段检查证件是否有被篡改痕迹。活体和一致性核验用户按照系统提示眨眼、转头、张嘴平台拿视频帧与证件照片做人脸比对确认上传的人和证件持有者是同一人。风险名单筛查平台把姓名、证件号、证件签发国家等信息放到制裁名单、政治公众人物名单、失信名单里做比对再决定是否通过。问题在于这整套流程的结果通常存在平台自己的数据库里。有的平台只保存“KYC 已通过”的状态有的平台会把证件正反面照片、人脸视频、姓名和证件号全部留存。用户对这些数据没有控制权不知道被存了多久也不知道可能被哪些内部系统读取。1.3 传统 KYC 在数字资产场景里暴露的问题数字资产场景天然是跨平台、跨地域、需要频繁验证的。一个人可能同时使用三家交易所、两个钱包、一个 NFT 平台和一个链上借贷协议每个平台都要走一遍 KYC。结果就是同一张身份证在多个网站重复上传身份证照片和活体视频在多个中心化服务器里留存。这些中心化数据库一旦被拖库或内部人员泄露用户身份信息就会被批量打包出售。更麻烦的是用户无法知道自己手上的 KYC 记录在哪些系统里存在副本也没有办法统一撤回。传统 KYC 还有一个问题数据与凭证是绑死的。用户在 A 平台通过 KYC去 B 平台时无法直接使用必须再上传一次。A 平台如果倒闭或冻结账户用户的验证结果也随之失效。对普通人来说这既增加了操作成本也扩大了隐私泄露面积。2. 去中心化 KYC 的核心控制权、可验证证明、最小披露2.1 什么是去中心化 KYC不是什么去中心化 KYC 并不是“不需要 KYC”也不是“匿名就可以参与一切”。它改变的是 KYC 数据的所有权和验证方式。在传统模式里用户把身份原始数据交给平台平台负责保存和判断。在去中心化模式里身份信息仍然需要由可信发行方来做验证但验证结果会被封装成可验证凭证交还到用户自己的数字身份侧。用户后续向其他平台证明“我已经通过 KYC”时不再需要把身份证照片重新交出去只需要出示那张凭证或者出示基于凭证生成的最小化证明。所以去中心化 KYC 的目标是平台仍能完成合规验证但用户不必把所有隐私原件都复制给每个平台。它尝试把“身份验证”和“隐私泄露”解耦。2.2 DID 与 VC身份标识和可验证凭证去中心化 KYC 体系里有三个基础概念DID、VC、VP。DID 是去中心化标识符。它是一串由用户控制的唯一 ID比如did:kyc:example:user-1234。这个 ID 可以跟用户的公钥绑定用户持有对应的私钥就能证明“我确实控制这个身份标识”。DID 本身不包含姓名、身份证号更多是提供一个稳定的身份锚点。VC 是可验证凭证。发行方对用户完成 KYC 后会签发一份带有数字签名的凭证。凭证里包含“谁的凭证”“发行方是谁”“KYC 结果是什么”“什么时候过期”“如何查询吊销状态”等信息。因为凭证带有发行方签名验证方不需要调用发行方数据库也能确认凭证没有被篡改。VP 是可验证演示。用户向某平台出示 VC 时不是直接把整个凭证原封不动扔过去而是把需要的部分字段组装成一个可验证演示并用自己的私钥签名。这样验证方既能验证凭证来自可信发行方又能确认“当场出示凭证的人就是用户本人”。2.3 零知识证明与选择性披露去中心化 KYC 最有价值的一点是支持选择性披露。用户不需要把 VC 里的所有字段都展示给验证方。举个例子某个平台只要求用户超过 18 岁。传统做法是上传身份证平台看到姓名、出生日期、住址、身份证号。去中心化方案可以让用户出示一张“年龄大于 18 岁”的证明而不暴露具体出生日期。这种能力依赖零知识证明。用比较通俗的方式理解用户向系统证明“我拥有一张由可信发行方签发的凭证凭证里记录了年龄字段年龄大于 18”但不会把年龄字段本身披露出去。验证方可以验证证明为真却看不到背后的原始数据。这在技术上比单纯下载 VC、解析 JSON 要复杂但隐私保护效果更好。2.4 链上存证与链下数据如何划分去中心化 KYC 常被误解为“把所有身份信息写到区块链上”。准确的设计通常是把链上链下分开。链上只放必要状态比如凭证编号的哈希。凭证签发方的 DID。凭证吊销状态的合约状态。用户 DID 与某个链上认证状态的关联关系。链下保存或由用户自持的数据包括身份证照片原件。人脸视频。姓名、住址等字段。VC 的明文内容或加密密文。区块链在这里不是存身份证图片的大仓库而是一个公开状态记录层。即使验证方在区块链浏览器里看到某个凭证编号状态是“有效”或“吊销”也无法直接看到用户的身份证照片。这种设计可以兼顾验证效率和隐私保护。对比项传统中心化 KYC去中心化 KYC身份原始数据由平台数据库集中保存由用户或可信机构自持按需出示重复验证成本每个平台重新上传一次签发多处可验证隐私披露粒度常见做法是全部字段可见可以选择性披露或零知识证明数据泄露影响单点泄露导致批量身份冒用分散持有减小单点泄露半径合规责任平台自行承担高风险平台仍要承担合规责任但数据处理范围变小技术复杂度低流程成熟高依赖签名、DID、凭证协议3. 对普通人有什么用从反复提交证件到“只给必要信息”3.1 避免每个平台都保存一份身份证副本普通人对 KYC 最直观的困扰不是注册那几分钟而是注册之后。今天在 A 交易所上传身份证明天在 B 平台再做一次后天参加某个 NFT 白名单活动又要验证。每多一个平台就多一份身份数据副本。去中心化 KYC 的理想状态是可信身份服务商只做一次严格核验然后给用户签发可验证凭证。用户之后遇到第二个、第三个平台时平台通过验证凭证来决定是否放行而不是再次索取身份证原件。这个模式相当于把“身份验证结果”变成了一张可以反复使用的数字凭证。但要注意凭证不是无限期的。凭证通常有有效期比如一年或两年。到期后需要回到发行方重新更新。这仍然比每次都要完整上传证件、做人脸识别省事得多。3.2 按需披露证明“已成年”只需要一个布尔值如果你是学生或普通用户可能觉得“年龄超过 18”这个证明已经很简单。但传统 KYC 里平台为了确认这一点会拿到你的全部身份证信息。平台只需要知道“是否满 18 岁”却连你的精确出生日期、住址、证件号码都看到了。去中心化 KYC 的选择性披露可以在技术上减少这种“过度收集”。验证方只能拿到自己真正需要的事件结果比如ageOver18: true或kycStatus: Approved。至于姓名、住址、精确生日可以不出现在出示的 VP 中。这个能力对现实世界同样有价值。无论是注册数字钱包、登录 Web3 游戏还是验证 Discord 社区身份都可以用“最小必要字段”完成。对普通人来说这是最直接、最容易感知的隐私收益。3.3 平台数据泄露后身份风险依然存在但范围变小中心化数据库泄露的新闻已经不少见。如果用户把所有证件都存到十几个平台任何一个平台被拖库泄露的都是完整身份信息。攻击者可能利用这些信息办理贷款、注册手机号、骗取其他平台客服信任。去中心化 KYC 不能保证平台不泄露但它能让“泄露出去的”不是完整身份原价而是一张有时效、可吊销、可能只包含部分字段的凭证。凭证被泄露后用户可以联系发行方吊销验证方也会检查吊销状态从而降低凭证被长期利用的风险。当然这并不意味着去中心化 KYC 是万能解药。如果用户把身份证原件上传给一个不可信发行方发行方又把数据卖了隐私仍然会泄露。技术方式改变的是数据分发模式不能抹杀掉“必须选择可信服务方”这一前提。3.4 凭证可以更新、撤销、迁移身份不锁定在某一家平台中心化 KYC 很容易把用户绑定在平台内部。你在 A 平台做的认证结果A 平台如果不开放接口其他平台根本拿不到。如果你在 A 平台的账号被封之前提交的身份信息也无法转出。去中心化 KYC 把凭证交给用户控制后身份与具体平台解耦。用户可以在多个钱包或应用里持有同一张凭证只要私钥不丢就能把它出示给不同验证方。凭证丢失后可以通过发行方流程重新签发凭证过期后也可以更新。不过“可迁移”也带来新的使用责任。用户必须管理好自己的私钥或助记词。私钥丢了凭证就找不回来私钥被人拿去凭证也有可能被别人冒用。对普通人来说去中心化身份的第一课不是操作流程而是私钥管理。3.5 在交易所、空投、DAO 中的实际场景去中心化 KYC 的现实落地已经超过概念阶段。在加密货币交易所法币进出金和高风险交易仍然需要完整合规流程但一些分层场景已经开始尝试“轻量验证”。比如只验证“你不是美国受制裁地区的用户”或者只验证“单笔交易不超过某额度的用户已经完成基础身份确认”。在空投或 NFT 白名单活动中项目方最怕的是一个人注册几百个地址来刷奖励。去中心化 KYC 可以提供一个关键布尔值“该地址对应一个唯一真实用户”。用户不需要把身份证发给项目方项目方也能降低批量刷号风险。DAO 社区也有类似需求。一些 DAO 要限制某个角色只能由真实用户担任或者要保证一票一权。使用可验证凭证给钱包地址绑定一层“人格证明”可以在不暴露真实身份的前提下提高治理质量。这些场景的共同点是“平台需要验证用户的真实性但不需要看用户的私密证件”。这正是去中心化 KYC 最合适的应用区间。3.6 对“圆周率类项目”要冷静看待中文社区有时会把一些强调手机即可参与的区块链项目统称为“圆周率类项目”其中有项目也会要求在 App 内完成 KYC 或人脸识别。这里先不展开具体项目背景也不做投资评价只说身份验证层面的共性规律。无论一个项目叫“圆周率”还是其他名字只要它要求用户提交身份证、人脸视频或助记词就要先回答几个问题数据存在哪里谁会访问这些数据验证结果是否可以被吊销项目团队是否公布了清晰的身份数据政策和联系方式很多移动端项目把 KYC 包装成“给用户发数字身份”的手段但实际流程仍是中心化收集甚至比传统平台更容易让用户放松警惕。不要因为项目带了“区块链”“Web3”标签就默认它是去中心化 KYC。一个系统是不是去中心化要看身份数据由谁控制、用户能否自主出示验证结果而不是看项目白皮书里写了多少术语。4. 最小可理解流程签发、持有、出示、验证4.1 三个角色与一个信任模型要理解去中心化 KYC 的运行可以看一个最小流程。它只涉及三个角色发行方执行真实身份核验并签发 VC 的机构比如银行、持证身份服务商、合规钱包。持有者被核验通过的用户凭私钥控制自己的 DID 和 VC。验证方需要确认用户通过 KYC 的平台比如交易所、项目方、DAO。信任模型并不复杂验证方不一定信任每个用户但它信任发行方对用户身份的核验。发行方给用户签了一张带有签名的凭证用户用自己的私钥出示这张凭证验证方检查签名、有效期和吊销状态就能得出结论该用户确实通过过发行方认证。4.2 发行方签发一张 KYC 可验证凭证下面是一张示意性质的 VC。它不代表任何具体协议只是用来展示字段结构{ context: [https://www.w3.org/2018/credentials/v1], id: urn:uuid:0d8f5d4b-5d4a-4a9f-b0c5-2f3a66e2c3b2, type: [VerifiableCredential, IdentityKycCredential], issuer: did:kyc:example:issuer-abcd, issuanceDate: 2025-01-01T00:00:00Z, expirationDate: 2026-01-01T00:00:00Z, credentialSubject: { id: did:kyc:example:user-1234, kycStatus: Approved, countryOfResidence: SG, ageOver18: true }, credentialStatus: { id: https://status.example.com/credentials/status/0d8f5d4b, type: RevocationList2020 }, proof: { type: Ed25519Signature2020, created: 2025-01-01T00:00:00Z, proofPurpose: assertionMethod, verificationMethod: did:kyc:example:issuer-abcd#key-1, jws: eyJhbGciOiJFZERTQSIsImNyaXQiOlsiYjY0Il0sImI2NCI6ZmFsc2U..xxxxx } }这张凭证里issuer是发行方的 DIDcredentialSubject.id是用户 DIDcredentialStatus指向一个吊销查询接口proof.jws是发行方的数字签名。验证方拿到凭证后第一件事就是验签确认凭证没有被改过。真实实现中jws是一串合法编码不会出现xxxxx。这里的占位只是告诉大家“这里有一串签名值”。发行方还要保护好自己的签名私钥私钥一旦泄露签发的所有凭证都会失去信任。4.3 用户把凭证包装成演示文档并出示用户向平台出示身份时需要构造一份 VP。VP 的核心作用是让验证方确认“当前操作者确实持有凭证对应的私钥”。{ context: [https://www.w3.org/2018/credentials/v1], type: [VerifiablePresentation], holder: did:kyc:example:user-1234, verifiableCredential: [], proof: { type: Ed25519Signature2020, created: 2025-01-02T00:00:00Z, proofPurpose: authentication, verificationMethod: did:kyc:example:user-1234#key-1, challenge: random-challenge-from-verifier, jws: eyJhbGciOiJFZERTQSIsImNyaXQiOlsiYjY0Il0sImI2NCI6ZmFsc2U..xxxxx } }verifiableCredential数组在真实流程里要放入原始 VC或者放入经过选择性披露组合的派生凭证。challenge是验证方生成的随机数用于防止重放攻击。如果验证方上次收到的 VP 被原样重放因为挑战值不同新的验证会失败。在选择性披露场景里交给平台的数据会被裁剪。比如平台只需要确认ageOver18和kycStatusVP 里就不必包含countryOfResidence更不需要包含身份证图片。4.4 验证方完成签名、有效期、吊销状态三件事验证方收到 VP 后可以模拟以下请求完成校验curl -X POST https://verify.example.com/v1/presentations \ -H Content-Type: application/json \ -d presentation.json验证服务返回结果{ verified: true, checks: { signature: true, expirationDate: true, credentialStatus: notRevoked, presentationProof: true }, revealed: [kycStatus, ageOver18] }这个示意结果表达了三件事VC 的发行方签名有效凭证没有被篡改。VC 没有过期。凭证号在吊销列表里不存在即没有被撤销。VP 里的用户签名有效说明当前操作者确实持有了私钥。如果任何一项失败验证方应该拒绝服务。比如用户出示的凭证还在有效期内但发行方已经吊销了这张凭证验证方就必须视为无效。这是去中心化 KYC 比静态图片更可靠的关键点。4.5 参数速查表参数名含义常见值或注意点配置错误常见表现issuer凭证签发方 DID由可信机构和自己的签名密钥绑定验签失败身份来源不可信credentialSubject.id被证明用户的 DID应使用用户钱包 DID不能放身份证号凭证无法关联到真实用户expirationDate凭证过期时间按业务策略设置比如一年过期后被拒绝忘记续期credentialStatus吊销状态查询地址必须是可访问的 HTTPS URL验证超时或吊销不生效proof.jws签发方数字签名签名算法需要与公钥匹配伪造凭证签名校验失败holderVP 出示者 DID应与用户钱包 DID 一致身份被冒用或重放攻击参数没有统一的“标准答案”不同平台、不同规范实现细节会不同。落地前要先去查你使用的凭证协议和 SDK 文档核对版本要求。4.6 学习环境与生产环境的差异在学习环境里可以用本地内存存储 DID、VC把所有流程跑通即可。但生产环境要考虑的问题明显更多凭证私钥必须放到硬件安全模块或支持私钥保护的签名服务里不能放在普通服务器磁盘。吊销状态服务要高可用不能因为状态查询失败导致所有用户被卡住。用户私钥丢失怎么办生产系统需要有恢复流程也要在用户首次使用时讲清楚助记词备份。跨境用户的数据处理需要遵守不同司法辖区法律。学习时候可以先不考虑这些但在设计生产系统时缺任何一块都会变成事故。5. 常见误区和工程坑5.1 “去中心化 KYC 等于匿名”是最常见的误解很多人听到“去中心化”就以为匿名、无监管、不用给任何信息。这是错误的。去中心化 KYC 仍然需要发行方对用户做严格身份核验仍然可能涉及人脸比对和证件识别。它只是把“验证完毕后的结果”以凭证形式交还用户控制并不是让用户凭空变成匿名状态。对普通人的启示是哪怕你使用了最先进的可验证凭证系统只要真实世界发行方知道你的身份你的“匿名”就是有限的。不要因为某平台说自己用了去中心化技术就以为提交身份证也没有隐私风险。5.2 不要为了“上链”而上链身份证图片不适合明文上链区块链公开可读。身份证照片、护照照片、人脸视频一旦被明文写到链上任何人都可以下载且几乎无法彻底删除。即使后来吊销凭证明文内容也永久留在链上。正确做法是链上只放凭证哈希、状态索引和必要的 DID 信息证件图片和视频应当放在用户自持空间或受控存储中。项目方在选择架构时优先问一句这个字段是否必须公开如果不必须就不应该上链。5.3 只存哈希不等于可验证身份有些项目为了显得“去中心化”把身份证哈希存上链就说做了 KYC。实际上哈希本身并不能证明身份。身份证号码的哈希是单向的但如果攻击者提前准备好常见身份证号码字典可以通过撞库还原出部分原始值。更重要的是哈希无法解决“谁进行的验证”“谁签发了凭证”“凭证是否被吊销”这些核心问题。一个合规的去中心化 KYC 系统必须有明确的发行方、数字签名和凭证生命周期管理而不是只放一串哈希。5.4 问题现象与排查链路问题现象常见原因检查方式处理建议验证一直失败发行方 DID 和签名密钥不匹配核对 VC 的issuer与verificationMethod用正确的签发私钥重新生成凭证用户换手机后凭证消失私钥只存在旧设备检查钱包备份流程引导用户导入助记词或使用受控云备份吊销后凭证仍能通过吊销状态接口不可达或缓存过期curl 访问credentialStatus.id查看响应增加状态轮询和失败重试VP 重放攻击拦截失败验证方没有校验challenge检查 VP 校验逻辑强制随机挑战值并设置短时效用户年龄披露过度系统把原始 VC 原样透传查看 VP 中的revealed列表使用选择性披露或零知识证明排查时仍然按顺序进行先检查输入凭证是否是有效 JSON再检查 DID 和签名密钥是否匹配然后检查过期时间和吊销接口最后看验证方自己的网络、缓存和日志。很多问题不是密码学难题而是配置和运维问题。5.5 工程上容易反复踩的五个坑第一个坑是私钥管理不当。发行方、用户、验证方三方都有私钥任何一方泄露都会造成信任崩塌。生产环境不要使用硬编码私钥也不要放在镜像包里。第二个坑是凭证字段过度收集。不要把身份证号、人脸特征等敏感字段都塞进 VC更不要默认全部字段都进入 VP。设计 VC 时只放能支撑业务判断的最小字段。第三个坑是吊销链路缺失。没有吊销列表或者吊销接口不稳定等于给被泄露凭证留了后门。KYC 凭证必须有明确吊销方案团队要定期演练吊销流程。第四个坑是忽略用户体验。去中心化 KYC 对普通人来说有理解门槛如果注册流程没有解释清楚“私钥是什么”“为什么要备份”用户会直接流失或者因为误操作永远丢失凭证。第五个坑是合规责任不清晰。平台使用了去中心化 KYC 技术不等于平台不需要承担合规义务。监管问询时平台需要能说清楚身份核验由谁完成凭证来自哪个发行方用户数据去到哪里。只把技术名词写在白皮书里但拿不出可审计日志非常危险。6. 普通人如何保护数字身份一份可执行清单6.1 提交身份信息前先检查四件事第一平台是否告诉你数据保存位置和删除方式。如果平台只让你上传身份证却不提供隐私政策或删除入口就要谨慎。第二平台是否支持凭证导出。如果你完成的验证结果只能锁在 App 内无法被其他平台认可其实还是中心化锁定不是真正的可携带身份。第三平台是否只要求必要字段。比如平台只需要年龄却强制要求提供身份证号就说明它的隐私保护设计很粗糙。第四私钥是否由你掌控。如果平台声称“帮你保管私钥”却没有提供导入导出工具你的身份资产本质上仍在平台手里。6.2 数字身份使用检查清单检查项建议私钥备份离线或加密备份助记词不要截图存在相册凭证有效期确认过期时间提前安排续期吊销状态了解发行方怎么吊销凭证能否自助操作出示最小字段每次出示前问自己平台只需要什么信息平台资质确认发行方是否可信是否有明确主体和联系方式链上记录可审计确认链上只存状态不存证件明文客服和工单验证前测试平台客服能否响应用户问题这个清单可以打印成卡片也可以写在使用说明文档里。普通用户不需要掌握密码学细节但应该形成“先检查再提交”的习惯。6.3 团队落地去中心化 KYC 的工程建议团队在落地去中心化 KYC 时要优先做三件事。先定义凭证模型。明确发行方是谁、凭证类型是什么、包含哪些字段、有效期多久、谁来维护吊销列表。不要一开始就同时实现零知识证明先用字段裁剪完成最小可用流程。再做安全评审。对签名私钥的存储、用户私钥恢复、吊销服务高可用、验证方重放攻击防护这四个点必须有明确方案。最简单的方式是邀请外部安全工程师做一次 threat modeling 审计。最后做用户教育。普通用户不熟悉 DID 和 VP注册流程里要配合简单文案和演示动画。不要默认用户知道“助记词”和“私钥”有什么区别。生产环境还要考虑监控。对签名服务做指标监控对吊销接口做可用性监控对异常验证失败率做告警。身份系统一旦出问题影响面往往不是单个用户而是整个信任链。6.4 最适合继续深入的方向对想进一步学习的人可以从三条线继续。第一条线是标准协议。W3C 的 Verifiable Credentials 和 Decentralized Identifiers 文档是理解数据格式和交互流程的起点。阅读官方规范时重点关注issuer、credentialSubject、proof、credentialStatus等字段的定义。第二条线是密码学应用。了解数字签名、Merkle Tree、零知识证明的最小概念。不需要一开始就推导公式能理解“证明者知道某信息但不需要披露信息”的代码示例即可。第三条线是工程集成。找一套支持 DID 和 VC 的开源项目在本地搭建一个最小验证服务签发一张测试凭证再用另一个服务去验证。跑通过一次之后去中心化 KYC 就不再是模糊概念。数字身份是一个涉及标准、密码学、合规产品和用户体验交叉的领域。对普通人来说最重要的不是记住协议名称而是理解一个原则你的身份信息不应该被每个平台复制一份验证结果应该由你掌控需要的时候再按需出示。去中心化 KYC 目前还远未成熟不同项目之间的凭证标准兼容性、用户体验和监管政策仍在快速变化但随着链上应用越来越多身份验证方式被重构只是时间问题。普通人能做的是在读完这篇内容后下一次遇到 KYC 时多问自己一句平台是否真的需要我的全部信息还是只需要一个验证结果