今天开发群里又来了一条需求标题叫“用户隐私手机号分享”我的第一反应是手抖。做日常开发的人都知道凡是和手机号沾边的功能基本都逃不过一场拉扯用户要的是“方便联系”产品要的是“留住用户”运营要的是“流程好走”唯独开发要扛下“隐私安全”这口锅。这项目本身不大却让我被迫和产品、测试、运营各battle了一轮从方案评审到落地排期再到上线后半夜查bug踩的坑比预期多得多。我把这段经历整理出来包括思路、代码、踩坑和“吵架”经验给遇到类似“隐私手机号分享”需求的兄弟一个参考。1. 需求来了手机号不能裸奔先说清楚这个需求到底在解决什么问题。不理解的同事会觉得不就是把手机号展示给对方么复制粘贴一下就完事了。但实际上在很多业务场景里让用户直接看到对方手机号是会出人命的。1.1 这个需求要解决什么问题业务方提了一个场景二手交易平台里买家看中一台相机卖家希望留个电话直接聊或者某同城服务里用户约了上门维修需要把联系方式给师傅。听起来很简单——平台把卖家的手机号加密一下展示给买家就行。可问题在于手机号一旦从平台上泄露出去会发生什么买家拿到号码可能转手卖给中介卖家被骚扰电话打爆甚至有人利用手机号做精准诈骗。更麻烦的是现在监管层面对个人信息保护盯得很紧一旦出现用户投诉“平台泄露了我的手机号”轻则下架整改重则被约谈罚款。所以“隐私手机号分享”这个需求本质是要在“用户与用户需要建立联系”和“平台不能直接暴露真实手机号”之间找一条缓冲带。我梳理了一下这个需求必须满足几个硬性条件用户A和用户B能通过平台建立的通道联系但不让A直接看到B的真实号码。如果业务确实需要可以提供一个“短暂可用的展示形式”比如脱敏后的号码或者临时中间号。所有访问、分享、失效的行为都要能被追踪出了问题要能倒查。不能给用户增加过多的操作负担否则用户会绕开平台去找“微信号”“QQ号”之类的联系方式功能等于白做。这些条件一列出来正常开发的思路就会往“脱敏展示”/“虚拟号”上靠。但做产品的人往往不这么想他们看到的是“用户想直接打个电话”于是第一版需求就写成了“下单成功后展示对方完整手机号并支持一键拨打”。1.2 为什么开发者第一反应是拒绝我当时在评审会上看到“展示完整手机号”几个字差点把水喷出来。直接亮真实手机号是隐私合规的红线不是开发偷懒而是真不敢碰。拿数据安全的角度讲手机号属于敏感个人信息和姓名、身份证号一样在《个人信息保护法》里受到严格约束。平台存储手机号都需要最小化原则更别说主动把手机号展示给另一个陌生人。一旦用户举报平台必须证明自己“经过了单独同意”“遵循了最小必要”等要求。而现实中用户并不会仔细看隐私政策到时候解释成本极高。从技术落地的角度展示完整手机号也会带来一系列问题页面被爬虫抓取怎么办分享链接被恶意转发怎么办手机号被截图传播平台怎么撤回这些问题不是代码写不出来而是写了之后无法收场。我那时就跟产品说你要显示完整号也简单我两天就能上线但三天后你可能要去处理用户投诉风险你自己扛。这么一说产品才愿意坐下来听方案。所以这里想分享的第一个经验是battle不是态度上的强硬而是要把“为什么不能这么做”的风险给业务方拆开揉碎讲清楚。开发不是挡业务而是帮业务把雷提前排掉。2. 方案选型能显示完整号吗不能既然“裸奔”不行就得找替代方案。隐私手机号分享的常规路径行业里基本有三种脱敏展示、AXB中间号、授权转发。不同方案的成本、体验、合规表现各不相同需要结合自身业务规模和资源做取舍。2.1 三个主流方案对比我先把三种方案的核心思想介绍一遍都是开发日常能接触到的脱敏展示最常见的做法把手机号中间四位用*代替只显示前三位和后四位。用户看到的是“138****8888”想联系就需要通过平台的内置按钮在线聊天、拨号中转来间接发起。优点是改造简单、成本低缺点是不能直接拨打沟通体验会打折。AXB中间号这是运营商的能力平台申请一批“中间号X”用户A打给中间号X运营商转接给真实号码B。这样双方都不知道对方的真实号码。优点是体验接近直接拨打缺点是依赖运营商资源每一路通话都产生费用而且需要申请资质小团队短时间搞不定。授权转发也可以做成临时链接或隐私号卡片用户A通过平台打开一个链接链接里展示脱敏号码/未脱敏号码但带水印并设置有效期比如24小时。过期后链接失效无法继续访问。优点是可以精确控制访问范围缺点是需要自己做一套授权令牌管理。我把三方对比做成了表格方便后面评审用方案可拨打性隐私强度改造成本使用成本适合场景脱敏展示低需平台转接高号码不泄露低无低频、在线咨询类AXB中间号高接近直拨高双方互相隐藏中高每次通话收费高频、撮合交易类授权转发中可播可不播较高可持续控制中低低频、偶发联系类2.2 为什么我选了授权转发脱敏组合我们的项目情况比较特殊用户之间不是高频沟通一般一笔订单只联系几次团队也没有运营商背景中间号资源申请周期长谈不下来业务方又强烈要求“最好能直接拨打电话”。综合考虑后我提了一个组合方案常规展示走脱敏特殊场景走授权转发。具体来说用户A浏览页面时默认只看到脱敏号码138****8888。如果A确实需要联系对方点击“申请联系方式”系统生成一个带签名的授权链接有效期为24小时。授权链接内显示真实手机号但页面会打上包含“分享人访问人时间戳”的水印防止截图泄露。同时链接自带一次性的转移限制A把链接转发给CC打开后会被拦截因为授权和用户身份绑定。这个方案既满足了“能联系上”的业务述求又保证了“平台不主动暴露完整号码”的底线。更重要的是它不需要任何外部API合作开发周期可以压缩到一周以内。选这个方案还有一个原因它给后面的业务留了退路。如果以后真的要上AXB中间号只需要在“申请联系方式”这个动作里接入运营商接口替换底层的拨号逻辑即可对用户的前端体验影响很小。2.3 评审会上怎么说服他们方案选完最难的环节来了——说服产品接受“不能直接展示完整手机号”这件事。我当时准备了一张图把风险分了三层第一层是“平台风险”用户手机号被批量爬取导致平台陷入隐私丑闻。第二层是“用户风险”用户被骚扰甚至诈骗必然归咎于平台。第三层是“法律风险”监管要求查验时平台无法自证获得用户授权。产品最怕的不是技术做不到而是最后背锅。于是我从“出了事咱们一起兜不住”的角度切入很快产品就同意调整需求优先级。所以和产品battle的一个重要技巧是别站在“开发做不到”的角度说要站在“业务风险不可控”的角度说。3. 落地实操代码比想象中多一步方案定了剩下的就是实施。这个功能看起来只是“显示号码”但真正写起来涉及数据库设计、令牌生成、脱敏算法、防滥用策略、日志审计一环都不能少。我把整个实现过程复盘一遍重点说关键细节。3.1 数据库设计敏感字段加密存储老规矩手机号不能明文存。虽然数据库有权限控制但为了防DBA和运气不好时数据库被拖库手机号字段必须加密。我用的方案是应用层做AES-256-GCM加密密钥放配置中心数据库里存密文。同时新建了两张表share_record和share_token分别是分享记录表和授权令牌表。字段设计如下以MySQL为例-- 分享记录表 CREATE TABLE share_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_id VARCHAR(64) NOT NULL, owner_user_id VARCHAR(32) NOT NULL, guest_user_id VARCHAR(32) NOT NULL, phone_encrypt VARBINARY(512) NOT NULL COMMENT 真实手机号密文, phone_masked VARCHAR(20) NOT NULL COMMENT 脱敏后的手机号展示, status TINYINT NOT NULL DEFAULT 1 COMMENT 1可用 2已撤销 3过期, created_at DATETIME NOT NULL, expired_at DATETIME NOT NULL, revoked_at DATETIME NULL, INDEX idx_order_guest (order_id, guest_user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 授权令牌表 CREATE TABLE share_token ( id BIGINT PRIMARY KEY AUTO_INCREMENT, share_record_id BIGINT NOT NULL, token_hash CHAR(64) NOT NULL COMMENT token哈希防止DB泄露后可以伪造, access_user_id VARCHAR(32) NOT NULL, access_times INT NOT NULL DEFAULT 0 COMMENT 访问次数, max_access_times INT NOT NULL DEFAULT 5 COMMENT 最大访问次数限制, expires_at DATETIME NOT NULL, created_at DATETIME NOT NULL, INDEX idx_token_hash (token_hash) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这里有个很容易被忽视的点token字段一定不要存明文要存哈希。很多开发在写类似功能时会直接把token放进数据库方便校验。但如果数据库被拖走攻击者拿着token就能访问所有分享页等于白做了。所以我用token base64url(random_bytes(32))生成存储时用SHA-256哈希。校验时先哈希再比对这样数据库泄露也不会导致token泄露。同时share_record里的phone_encrypt字段旁边还存了phone_masked是为了在列表页、消息页快速展示脱敏号码不用每次解密手机号去脱敏减少加密解密的开销。3.2 脱敏和授权分享的核心逻辑脱敏算法本身很简单但要注意标准化。手机号有可能是138 8888 8888这种带空格格式还有可能是86 13888888888必须先做清洗。我写了个工具函数用的思路是先过滤非数字再统一按11位处理import re def mask_mobile(phone: str) - str: # 去除所有非数字字符 digits re.sub(r\D, , phone) # 如果带86去掉前缀 if len(digits) 14 and digits.startswith(86): digits digits[2:] if len(digits) ! 11: raise ValueError(finvalid phone: {phone}) return digits[:3] **** digits[7:]对应的校验手机号也要做同样的清洗避免数据库里出现两个格式不同但实际相同的号码。这块我在测试阶段遇到过后面在常见问题里细说。授权分享的时序是这样的用户A点击“申请联系方式”。后端从订单上下文中拿到收款侧用户B的手机号密文。判断当前订单是否存在有效分享记录若存在直接复用避免重复生成。生成token和授权链接链接格式为/share/contact?tokenxxx。用户A打开链接时后端校验token、到期时间、访问次数、用户身份。校验通过后返回真实手机号但中间插入前端水印脚本。关键代码如下节选from datetime import datetime, timedelta import hashlib import secrets def create_share_token(order_id: str, owner_user_id: str, guest_user_id: str): # 检查是否已有可用记录 existing db.query( SELECT share_record_id FROM share_record WHERE order_id %s AND status 1 AND expired_at NOW() LIMIT 1 , (order_id,)) if existing: # 如果share_token表已有该记录token直接返回 ... return existing[share_record_id] # 新生成分享记录 record_id db.insert( INSERT INTO share_record (order_id, owner_user_id, guest_user_id, phone_encrypt, phone_masked, status, created_at, expired_at) VALUES (%s,%s,%s,%s,%s,1,%s,%s) , (order_id, owner_user_id, guest_user_id, encrypt_phone(phone), mask_phone(phone), now, now timedelta(hours24))) # 生成随机token token secrets.token_urlsafe(32) token_hash hashlib.sha256(token.encode()).hexdigest() db.insert( INSERT INTO share_token (share_record_id, token_hash, access_user_id, expires_at, created_at) VALUES (%s,%s,%s,%s,%s) , (record_id, token_hash, guest_user_id, now timedelta(hours24), now)) return record_id, token在用户访问/share/contact时需要再次校验用户身份。不要把token作为唯一凭证否则只要有人把链接发出来任何人都能打开。正确做法是token绑定guest_user_id访问时校验当前登录用户和token的access_user_id一致。不一致直接拒绝。这才是授权分享的核心语义。3.3 水印和防滥用把细节做深真实手机号一旦展示截图、拍照这些线下泄露行为是技术无法完全阻止的。但这不代表我们什么都不能做至少可以做到事后可追溯。我在页面模板里加了一个水印层用CSS生成包含“当前登录用户ID 订单号末四位 时间戳”并做成半透明、倾斜、平铺的样式。这样即使有人截图一旦流传出去里面也有对方自己的身份信息能起到威慑作用。防滥用方面我设置了三个限制访问次数上限同一个token最多访问5次超出即失效防止被接口工具高频抓取。IP频率限制同一个IP一分钟内最多访问10次同时支持动态调整。token失效时间24小时内有效。如果业务需要可以改成“订单完成后48小时内有效”。限流这一步很容易被忽略但一旦上线发现有人写脚本循环调用接口就能把全站手机号脱敏后的数据拉走那就真的来不及补了。所以还在网关层加了一把锁只要短时间内对/share/contact的请求量超过阈值直接返回429并触发告警。3.4 撤销逻辑给用户一个反悔的按钮分享出去的联系方式不应该只有“等它过期”这一条路。用户B在订单完成后可能反悔了或者遭到骚扰这时候必须能主动撤销。我在订单详情页提供一个“停止分享”按钮调用接口把share_record.status从1改成2同时将该记录下所有未过期的token都标记为失效。撤销之后用户A再打开链接看到的是“该联系方式已失效”。需要注意的是撤销和过期是两种状态最好都记录时间不要覆盖。我在表里就预留了revoked_at字段方便后续审计从哪一刻开始链接就不可用了。这些日志在用户投诉时非常有用能直接证明平台在哪个时间点切断了曝光。4. 和产品经理battle的那几轮这部分其实比写代码更精彩。前面说了方案但真正实施过程里产品、运营、测试各有各的诉求每一个诉求背后都可能让方案变形。我整理了三轮典型的冲突应该能给你一些经验。4.1 第一轮产品说“看不到完整号用户怎么发短信”产品经理拿了一个用户调研结果过来说很多用户习惯在交易前发短信确认地址。如果只显示脱敏号码用户没法发短信体验会很差。我的应对方式不是拒绝而是给一个折中方案平台提供“在线留言”功能同时帮助用户一键生成一条包含订单信息的短信模板只不过收信人是平台虚拟号。用户点击发送时请求会通过后端转发到对方并附加平台提示“您有一条来自×平台的消息”。这样用户有“发短信”的感觉但实际号码又被保护住了。本质上是把“用户与用户直接联系”变成“通过平台代理联系”在体验和隐私之间做了一个平衡。4.2 第二轮运营说“导出通话记录做客服判断”运营提出如果用户投诉“联系不上对方”客服需要看到双方真实的通话记录和手机号以便人工介入。这个诉求很合理但不能直接把手机号导出到Excel里。我给运营做了一个专门的客服工作台客服在内部管理后台搜索订单时能查看脱敏号码和隐藏若干位的完整号如果要查看明文需要单独申请临时权限并且后台操作全程审计每次查看都会留下日志。这个方案在合规上站得住脚因为“可以看”和“可以下载”是两码事。实践中我还给操作日志里记录了访问者的账号、IP、时间和查看原因。一旦出现内鬼可以直接定位责任人。我们不需要假设所有运营都有恶意但在系统设计上必须默认所有内部人员都是潜在风险方。4.3 第三轮测试说“联调环境没法验证真机拨打”测试同事反馈说脱敏逻辑在测试环境没问题但“申请联系”功能如果走真实短信通道需要真实手机号导致自动化测试跑不通。这个问题让我意识到大家不是故意找茬而是环境限制了验证。于是我在代码里加了一个隐私白名单开关如果当前用户手机号属于测试白名单比如以1880000xxxx结尾系统会自动跳过授权直接展示脱敏后的完整测试号并打上“测试模式”的标记。这样可以保证开发环境、测试环境能跑通全链路生产环境又不会受开关影响。当然这个开关必须放到配置中心并且线上环境强制关闭绝不能做成“传参就能开启”的作弊口子。经过三轮battle我的总结是开发不能只做“技术实现者”还要做“业务风险兜底者”。产品提需求时不知道风险运营看数据时不关心合规测试在乎功能能不能跑通。我们要做的是在尊重各方诉求的前提下找到一个在隐私边界内实现目标的方案。好处是一旦你把替代方案做出来对方通常都会接受。这个比单纯说“不行”有效一万倍。5. 常见问题与排查实录上线之后各种奇奇怪怪的bug才真正涌出来。这里记录几个典型问题算是给后来者一个避坑清单。5.1 授权链接一直失效用户被卡在“无效分享”现象用户A在订单页申请联系方式后点击链接发现提示“链接已失效”但明明还没过24小时。排查过程第一反应是token过期时间计算有问题。仔细看日志发现用户A访问链接时带了一个from参数导致路由匹配走了另一个方法而那个方法里根本没有校验token的有效期直接返回默认的“已失效”。还有一个原因是服务器时区设置成UTC数据库里存的expired_at是UTC时间但前端显示的是北京时间也就是差8小时手动测试时把时间算错了。修正方案统一所有时间都以UTC时间存储展示时由前端做时区转换服务端只认UTC时间。token失效判断时不再用“当前时间小于expired_at”而是用“expired_at大于now”这种纯数据库比较避免应用服务器时区不一致。5.2 脱敏结果“1388888”变成“13888??”现象有些手机号脱敏后出现了乱码或者位数不对。原因是数据库里存的手机号包含空格、横杠或者86前缀。我在清洗函数里做了处理但有些老数据写入时没有走同一个清洗函数导致直接调用mask_mobile时抛异常或者返回14位。处理方式写了一个一次性数据订正脚本把所有phone字段重新清洗并给相关表加了CHECK约束或者应用层校验确保新的写入手机号都经过统一清洗后再入库。同时更新了脱敏函数遇到“86”前缀主动去掉避免脱敏结果出现非数字符号。5.3 授权链接被转发了导致陌生人看到手机号现象用户A把链接转发到微信群里群里其他人点开后居然也能看到完整手机号。当时第一版校验只做了token校验没有绑定用户身份导致只要有链接就能访问。修复方式在token表里加上access_user_id字段并在访问时与当前登录用户ID比对。同时链接携带唯一user标识后端取当前会话里的用户信息不信任链接参数里的用户ID。这样即使链接被转发其他登录用户也打不开。5.4 日志里手机号全是明文这是隐蔽问题。虽然业务接口返回的是脱敏号但我在日志切面里把整个请求参数打印出来了其中包含解密后的明文手机号字段。一旦日志系统被攻破数据照样泄露。解决之道在日志切面里对phone、mobile、phoneEncrypt等敏感字段做脱敏处理或者干脆不打印。还要检查异常堆栈里会不会带出SQL参数。这个点容易被新手忽略但属于合规检查的重点项。5.5 撤销接口被人批量调用现象撤销分享接口上线后发现有人循环调用把别人的分享记录都撤销了。原因是撤销接口只校验了“是否登录”没有校验“是否是分享记录的主人”。修复方案在撤销接口上增加权限判断只有分享记录的owner才能操作否则返回403。同时在数据库层也加上过滤条件避免绕过权限校验。这类越权漏洞其实很常见尤其是在涉及“通过ID操作”的接口上一定要把“资源归属”校验做扎实。6. 最后想说的那次项目上线后我坐在工位上想为什么一个看似简单的手机号分享功能能牵扯出这么多问题。后来想明白了越贴近用户信息的功能越需要敬畏。日常开发里我们常常为了赶进度把“展示手机号”当成一件小事但就是这样的小事一旦出了隐私泄露事故代价是整个团队几个月白干。所以不要觉得产品提什么就做什么该battle时就要battle起来。每次“battle”都不是为了怼人而是把一个隐藏风险放到桌面上摊开让所有人都意识到它的存在然后一起想出更稳妥的方案。后来我把这套“授权链接脱敏权限校验审计日志”的思路沉淀成了一个内部组件其他团队做类似功能时可以直接复用。如果你现在正面临“隐私手机号分享”的需求建议先别急着写代码而是跟业务方把三件事谈清楚能看什么、看多久、出问题找谁。这三件事谈明白代码怎么实现其实都是水到渠成的事。希望这篇复盘能帮你少踩几个坑。
隐私手机号分享功能开发复盘：脱敏、授权链接与防滥用实践
今天开发群里又来了一条需求标题叫“用户隐私手机号分享”我的第一反应是手抖。做日常开发的人都知道凡是和手机号沾边的功能基本都逃不过一场拉扯用户要的是“方便联系”产品要的是“留住用户”运营要的是“流程好走”唯独开发要扛下“隐私安全”这口锅。这项目本身不大却让我被迫和产品、测试、运营各battle了一轮从方案评审到落地排期再到上线后半夜查bug踩的坑比预期多得多。我把这段经历整理出来包括思路、代码、踩坑和“吵架”经验给遇到类似“隐私手机号分享”需求的兄弟一个参考。1. 需求来了手机号不能裸奔先说清楚这个需求到底在解决什么问题。不理解的同事会觉得不就是把手机号展示给对方么复制粘贴一下就完事了。但实际上在很多业务场景里让用户直接看到对方手机号是会出人命的。1.1 这个需求要解决什么问题业务方提了一个场景二手交易平台里买家看中一台相机卖家希望留个电话直接聊或者某同城服务里用户约了上门维修需要把联系方式给师傅。听起来很简单——平台把卖家的手机号加密一下展示给买家就行。可问题在于手机号一旦从平台上泄露出去会发生什么买家拿到号码可能转手卖给中介卖家被骚扰电话打爆甚至有人利用手机号做精准诈骗。更麻烦的是现在监管层面对个人信息保护盯得很紧一旦出现用户投诉“平台泄露了我的手机号”轻则下架整改重则被约谈罚款。所以“隐私手机号分享”这个需求本质是要在“用户与用户需要建立联系”和“平台不能直接暴露真实手机号”之间找一条缓冲带。我梳理了一下这个需求必须满足几个硬性条件用户A和用户B能通过平台建立的通道联系但不让A直接看到B的真实号码。如果业务确实需要可以提供一个“短暂可用的展示形式”比如脱敏后的号码或者临时中间号。所有访问、分享、失效的行为都要能被追踪出了问题要能倒查。不能给用户增加过多的操作负担否则用户会绕开平台去找“微信号”“QQ号”之类的联系方式功能等于白做。这些条件一列出来正常开发的思路就会往“脱敏展示”/“虚拟号”上靠。但做产品的人往往不这么想他们看到的是“用户想直接打个电话”于是第一版需求就写成了“下单成功后展示对方完整手机号并支持一键拨打”。1.2 为什么开发者第一反应是拒绝我当时在评审会上看到“展示完整手机号”几个字差点把水喷出来。直接亮真实手机号是隐私合规的红线不是开发偷懒而是真不敢碰。拿数据安全的角度讲手机号属于敏感个人信息和姓名、身份证号一样在《个人信息保护法》里受到严格约束。平台存储手机号都需要最小化原则更别说主动把手机号展示给另一个陌生人。一旦用户举报平台必须证明自己“经过了单独同意”“遵循了最小必要”等要求。而现实中用户并不会仔细看隐私政策到时候解释成本极高。从技术落地的角度展示完整手机号也会带来一系列问题页面被爬虫抓取怎么办分享链接被恶意转发怎么办手机号被截图传播平台怎么撤回这些问题不是代码写不出来而是写了之后无法收场。我那时就跟产品说你要显示完整号也简单我两天就能上线但三天后你可能要去处理用户投诉风险你自己扛。这么一说产品才愿意坐下来听方案。所以这里想分享的第一个经验是battle不是态度上的强硬而是要把“为什么不能这么做”的风险给业务方拆开揉碎讲清楚。开发不是挡业务而是帮业务把雷提前排掉。2. 方案选型能显示完整号吗不能既然“裸奔”不行就得找替代方案。隐私手机号分享的常规路径行业里基本有三种脱敏展示、AXB中间号、授权转发。不同方案的成本、体验、合规表现各不相同需要结合自身业务规模和资源做取舍。2.1 三个主流方案对比我先把三种方案的核心思想介绍一遍都是开发日常能接触到的脱敏展示最常见的做法把手机号中间四位用*代替只显示前三位和后四位。用户看到的是“138****8888”想联系就需要通过平台的内置按钮在线聊天、拨号中转来间接发起。优点是改造简单、成本低缺点是不能直接拨打沟通体验会打折。AXB中间号这是运营商的能力平台申请一批“中间号X”用户A打给中间号X运营商转接给真实号码B。这样双方都不知道对方的真实号码。优点是体验接近直接拨打缺点是依赖运营商资源每一路通话都产生费用而且需要申请资质小团队短时间搞不定。授权转发也可以做成临时链接或隐私号卡片用户A通过平台打开一个链接链接里展示脱敏号码/未脱敏号码但带水印并设置有效期比如24小时。过期后链接失效无法继续访问。优点是可以精确控制访问范围缺点是需要自己做一套授权令牌管理。我把三方对比做成了表格方便后面评审用方案可拨打性隐私强度改造成本使用成本适合场景脱敏展示低需平台转接高号码不泄露低无低频、在线咨询类AXB中间号高接近直拨高双方互相隐藏中高每次通话收费高频、撮合交易类授权转发中可播可不播较高可持续控制中低低频、偶发联系类2.2 为什么我选了授权转发脱敏组合我们的项目情况比较特殊用户之间不是高频沟通一般一笔订单只联系几次团队也没有运营商背景中间号资源申请周期长谈不下来业务方又强烈要求“最好能直接拨打电话”。综合考虑后我提了一个组合方案常规展示走脱敏特殊场景走授权转发。具体来说用户A浏览页面时默认只看到脱敏号码138****8888。如果A确实需要联系对方点击“申请联系方式”系统生成一个带签名的授权链接有效期为24小时。授权链接内显示真实手机号但页面会打上包含“分享人访问人时间戳”的水印防止截图泄露。同时链接自带一次性的转移限制A把链接转发给CC打开后会被拦截因为授权和用户身份绑定。这个方案既满足了“能联系上”的业务述求又保证了“平台不主动暴露完整号码”的底线。更重要的是它不需要任何外部API合作开发周期可以压缩到一周以内。选这个方案还有一个原因它给后面的业务留了退路。如果以后真的要上AXB中间号只需要在“申请联系方式”这个动作里接入运营商接口替换底层的拨号逻辑即可对用户的前端体验影响很小。2.3 评审会上怎么说服他们方案选完最难的环节来了——说服产品接受“不能直接展示完整手机号”这件事。我当时准备了一张图把风险分了三层第一层是“平台风险”用户手机号被批量爬取导致平台陷入隐私丑闻。第二层是“用户风险”用户被骚扰甚至诈骗必然归咎于平台。第三层是“法律风险”监管要求查验时平台无法自证获得用户授权。产品最怕的不是技术做不到而是最后背锅。于是我从“出了事咱们一起兜不住”的角度切入很快产品就同意调整需求优先级。所以和产品battle的一个重要技巧是别站在“开发做不到”的角度说要站在“业务风险不可控”的角度说。3. 落地实操代码比想象中多一步方案定了剩下的就是实施。这个功能看起来只是“显示号码”但真正写起来涉及数据库设计、令牌生成、脱敏算法、防滥用策略、日志审计一环都不能少。我把整个实现过程复盘一遍重点说关键细节。3.1 数据库设计敏感字段加密存储老规矩手机号不能明文存。虽然数据库有权限控制但为了防DBA和运气不好时数据库被拖库手机号字段必须加密。我用的方案是应用层做AES-256-GCM加密密钥放配置中心数据库里存密文。同时新建了两张表share_record和share_token分别是分享记录表和授权令牌表。字段设计如下以MySQL为例-- 分享记录表 CREATE TABLE share_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_id VARCHAR(64) NOT NULL, owner_user_id VARCHAR(32) NOT NULL, guest_user_id VARCHAR(32) NOT NULL, phone_encrypt VARBINARY(512) NOT NULL COMMENT 真实手机号密文, phone_masked VARCHAR(20) NOT NULL COMMENT 脱敏后的手机号展示, status TINYINT NOT NULL DEFAULT 1 COMMENT 1可用 2已撤销 3过期, created_at DATETIME NOT NULL, expired_at DATETIME NOT NULL, revoked_at DATETIME NULL, INDEX idx_order_guest (order_id, guest_user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 授权令牌表 CREATE TABLE share_token ( id BIGINT PRIMARY KEY AUTO_INCREMENT, share_record_id BIGINT NOT NULL, token_hash CHAR(64) NOT NULL COMMENT token哈希防止DB泄露后可以伪造, access_user_id VARCHAR(32) NOT NULL, access_times INT NOT NULL DEFAULT 0 COMMENT 访问次数, max_access_times INT NOT NULL DEFAULT 5 COMMENT 最大访问次数限制, expires_at DATETIME NOT NULL, created_at DATETIME NOT NULL, INDEX idx_token_hash (token_hash) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这里有个很容易被忽视的点token字段一定不要存明文要存哈希。很多开发在写类似功能时会直接把token放进数据库方便校验。但如果数据库被拖走攻击者拿着token就能访问所有分享页等于白做了。所以我用token base64url(random_bytes(32))生成存储时用SHA-256哈希。校验时先哈希再比对这样数据库泄露也不会导致token泄露。同时share_record里的phone_encrypt字段旁边还存了phone_masked是为了在列表页、消息页快速展示脱敏号码不用每次解密手机号去脱敏减少加密解密的开销。3.2 脱敏和授权分享的核心逻辑脱敏算法本身很简单但要注意标准化。手机号有可能是138 8888 8888这种带空格格式还有可能是86 13888888888必须先做清洗。我写了个工具函数用的思路是先过滤非数字再统一按11位处理import re def mask_mobile(phone: str) - str: # 去除所有非数字字符 digits re.sub(r\D, , phone) # 如果带86去掉前缀 if len(digits) 14 and digits.startswith(86): digits digits[2:] if len(digits) ! 11: raise ValueError(finvalid phone: {phone}) return digits[:3] **** digits[7:]对应的校验手机号也要做同样的清洗避免数据库里出现两个格式不同但实际相同的号码。这块我在测试阶段遇到过后面在常见问题里细说。授权分享的时序是这样的用户A点击“申请联系方式”。后端从订单上下文中拿到收款侧用户B的手机号密文。判断当前订单是否存在有效分享记录若存在直接复用避免重复生成。生成token和授权链接链接格式为/share/contact?tokenxxx。用户A打开链接时后端校验token、到期时间、访问次数、用户身份。校验通过后返回真实手机号但中间插入前端水印脚本。关键代码如下节选from datetime import datetime, timedelta import hashlib import secrets def create_share_token(order_id: str, owner_user_id: str, guest_user_id: str): # 检查是否已有可用记录 existing db.query( SELECT share_record_id FROM share_record WHERE order_id %s AND status 1 AND expired_at NOW() LIMIT 1 , (order_id,)) if existing: # 如果share_token表已有该记录token直接返回 ... return existing[share_record_id] # 新生成分享记录 record_id db.insert( INSERT INTO share_record (order_id, owner_user_id, guest_user_id, phone_encrypt, phone_masked, status, created_at, expired_at) VALUES (%s,%s,%s,%s,%s,1,%s,%s) , (order_id, owner_user_id, guest_user_id, encrypt_phone(phone), mask_phone(phone), now, now timedelta(hours24))) # 生成随机token token secrets.token_urlsafe(32) token_hash hashlib.sha256(token.encode()).hexdigest() db.insert( INSERT INTO share_token (share_record_id, token_hash, access_user_id, expires_at, created_at) VALUES (%s,%s,%s,%s,%s) , (record_id, token_hash, guest_user_id, now timedelta(hours24), now)) return record_id, token在用户访问/share/contact时需要再次校验用户身份。不要把token作为唯一凭证否则只要有人把链接发出来任何人都能打开。正确做法是token绑定guest_user_id访问时校验当前登录用户和token的access_user_id一致。不一致直接拒绝。这才是授权分享的核心语义。3.3 水印和防滥用把细节做深真实手机号一旦展示截图、拍照这些线下泄露行为是技术无法完全阻止的。但这不代表我们什么都不能做至少可以做到事后可追溯。我在页面模板里加了一个水印层用CSS生成包含“当前登录用户ID 订单号末四位 时间戳”并做成半透明、倾斜、平铺的样式。这样即使有人截图一旦流传出去里面也有对方自己的身份信息能起到威慑作用。防滥用方面我设置了三个限制访问次数上限同一个token最多访问5次超出即失效防止被接口工具高频抓取。IP频率限制同一个IP一分钟内最多访问10次同时支持动态调整。token失效时间24小时内有效。如果业务需要可以改成“订单完成后48小时内有效”。限流这一步很容易被忽略但一旦上线发现有人写脚本循环调用接口就能把全站手机号脱敏后的数据拉走那就真的来不及补了。所以还在网关层加了一把锁只要短时间内对/share/contact的请求量超过阈值直接返回429并触发告警。3.4 撤销逻辑给用户一个反悔的按钮分享出去的联系方式不应该只有“等它过期”这一条路。用户B在订单完成后可能反悔了或者遭到骚扰这时候必须能主动撤销。我在订单详情页提供一个“停止分享”按钮调用接口把share_record.status从1改成2同时将该记录下所有未过期的token都标记为失效。撤销之后用户A再打开链接看到的是“该联系方式已失效”。需要注意的是撤销和过期是两种状态最好都记录时间不要覆盖。我在表里就预留了revoked_at字段方便后续审计从哪一刻开始链接就不可用了。这些日志在用户投诉时非常有用能直接证明平台在哪个时间点切断了曝光。4. 和产品经理battle的那几轮这部分其实比写代码更精彩。前面说了方案但真正实施过程里产品、运营、测试各有各的诉求每一个诉求背后都可能让方案变形。我整理了三轮典型的冲突应该能给你一些经验。4.1 第一轮产品说“看不到完整号用户怎么发短信”产品经理拿了一个用户调研结果过来说很多用户习惯在交易前发短信确认地址。如果只显示脱敏号码用户没法发短信体验会很差。我的应对方式不是拒绝而是给一个折中方案平台提供“在线留言”功能同时帮助用户一键生成一条包含订单信息的短信模板只不过收信人是平台虚拟号。用户点击发送时请求会通过后端转发到对方并附加平台提示“您有一条来自×平台的消息”。这样用户有“发短信”的感觉但实际号码又被保护住了。本质上是把“用户与用户直接联系”变成“通过平台代理联系”在体验和隐私之间做了一个平衡。4.2 第二轮运营说“导出通话记录做客服判断”运营提出如果用户投诉“联系不上对方”客服需要看到双方真实的通话记录和手机号以便人工介入。这个诉求很合理但不能直接把手机号导出到Excel里。我给运营做了一个专门的客服工作台客服在内部管理后台搜索订单时能查看脱敏号码和隐藏若干位的完整号如果要查看明文需要单独申请临时权限并且后台操作全程审计每次查看都会留下日志。这个方案在合规上站得住脚因为“可以看”和“可以下载”是两码事。实践中我还给操作日志里记录了访问者的账号、IP、时间和查看原因。一旦出现内鬼可以直接定位责任人。我们不需要假设所有运营都有恶意但在系统设计上必须默认所有内部人员都是潜在风险方。4.3 第三轮测试说“联调环境没法验证真机拨打”测试同事反馈说脱敏逻辑在测试环境没问题但“申请联系”功能如果走真实短信通道需要真实手机号导致自动化测试跑不通。这个问题让我意识到大家不是故意找茬而是环境限制了验证。于是我在代码里加了一个隐私白名单开关如果当前用户手机号属于测试白名单比如以1880000xxxx结尾系统会自动跳过授权直接展示脱敏后的完整测试号并打上“测试模式”的标记。这样可以保证开发环境、测试环境能跑通全链路生产环境又不会受开关影响。当然这个开关必须放到配置中心并且线上环境强制关闭绝不能做成“传参就能开启”的作弊口子。经过三轮battle我的总结是开发不能只做“技术实现者”还要做“业务风险兜底者”。产品提需求时不知道风险运营看数据时不关心合规测试在乎功能能不能跑通。我们要做的是在尊重各方诉求的前提下找到一个在隐私边界内实现目标的方案。好处是一旦你把替代方案做出来对方通常都会接受。这个比单纯说“不行”有效一万倍。5. 常见问题与排查实录上线之后各种奇奇怪怪的bug才真正涌出来。这里记录几个典型问题算是给后来者一个避坑清单。5.1 授权链接一直失效用户被卡在“无效分享”现象用户A在订单页申请联系方式后点击链接发现提示“链接已失效”但明明还没过24小时。排查过程第一反应是token过期时间计算有问题。仔细看日志发现用户A访问链接时带了一个from参数导致路由匹配走了另一个方法而那个方法里根本没有校验token的有效期直接返回默认的“已失效”。还有一个原因是服务器时区设置成UTC数据库里存的expired_at是UTC时间但前端显示的是北京时间也就是差8小时手动测试时把时间算错了。修正方案统一所有时间都以UTC时间存储展示时由前端做时区转换服务端只认UTC时间。token失效判断时不再用“当前时间小于expired_at”而是用“expired_at大于now”这种纯数据库比较避免应用服务器时区不一致。5.2 脱敏结果“1388888”变成“13888??”现象有些手机号脱敏后出现了乱码或者位数不对。原因是数据库里存的手机号包含空格、横杠或者86前缀。我在清洗函数里做了处理但有些老数据写入时没有走同一个清洗函数导致直接调用mask_mobile时抛异常或者返回14位。处理方式写了一个一次性数据订正脚本把所有phone字段重新清洗并给相关表加了CHECK约束或者应用层校验确保新的写入手机号都经过统一清洗后再入库。同时更新了脱敏函数遇到“86”前缀主动去掉避免脱敏结果出现非数字符号。5.3 授权链接被转发了导致陌生人看到手机号现象用户A把链接转发到微信群里群里其他人点开后居然也能看到完整手机号。当时第一版校验只做了token校验没有绑定用户身份导致只要有链接就能访问。修复方式在token表里加上access_user_id字段并在访问时与当前登录用户ID比对。同时链接携带唯一user标识后端取当前会话里的用户信息不信任链接参数里的用户ID。这样即使链接被转发其他登录用户也打不开。5.4 日志里手机号全是明文这是隐蔽问题。虽然业务接口返回的是脱敏号但我在日志切面里把整个请求参数打印出来了其中包含解密后的明文手机号字段。一旦日志系统被攻破数据照样泄露。解决之道在日志切面里对phone、mobile、phoneEncrypt等敏感字段做脱敏处理或者干脆不打印。还要检查异常堆栈里会不会带出SQL参数。这个点容易被新手忽略但属于合规检查的重点项。5.5 撤销接口被人批量调用现象撤销分享接口上线后发现有人循环调用把别人的分享记录都撤销了。原因是撤销接口只校验了“是否登录”没有校验“是否是分享记录的主人”。修复方案在撤销接口上增加权限判断只有分享记录的owner才能操作否则返回403。同时在数据库层也加上过滤条件避免绕过权限校验。这类越权漏洞其实很常见尤其是在涉及“通过ID操作”的接口上一定要把“资源归属”校验做扎实。6. 最后想说的那次项目上线后我坐在工位上想为什么一个看似简单的手机号分享功能能牵扯出这么多问题。后来想明白了越贴近用户信息的功能越需要敬畏。日常开发里我们常常为了赶进度把“展示手机号”当成一件小事但就是这样的小事一旦出了隐私泄露事故代价是整个团队几个月白干。所以不要觉得产品提什么就做什么该battle时就要battle起来。每次“battle”都不是为了怼人而是把一个隐藏风险放到桌面上摊开让所有人都意识到它的存在然后一起想出更稳妥的方案。后来我把这套“授权链接脱敏权限校验审计日志”的思路沉淀成了一个内部组件其他团队做类似功能时可以直接复用。如果你现在正面临“隐私手机号分享”的需求建议先别急着写代码而是跟业务方把三件事谈清楚能看什么、看多久、出问题找谁。这三件事谈明白代码怎么实现其实都是水到渠成的事。希望这篇复盘能帮你少踩几个坑。
