面试官在你的项目中用户手机号是怎么存储的我们都知道手机号属于敏感个人信息必须加密存储。那如果现在有一个需求运营后台需要支持按手机号尾号4位快速筛选用户同时还要满足《个人信息保护法》和等保2.0的合规要求你会怎么设计常见错误回答踩坑点❌ 把密文解密后在内存里过滤尾号问题百万级以上数据直接 OOM性能灾难完全不可用❌ 用 LIKE %xxxx 直接查密文字段问题AES/SM4 加密后是随机字符串密文尾号和明文尾号没有任何关系查不到任何结果❌ 只加密中间 4 位首尾明文存储问题严重不合规数据库拖库后直接泄露完整手机号现在没有任何大厂会这么做❌ 单独建一张尾号映射表存尾号和用户 ID 的关系问题冗余度高维护一致性麻烦不如直接冗余字段高效标准满分回答大厂通用方案我会采用全号密文 脱敏展示冗余 尾号明文索引的三字段设计方案这也是目前国内互联网行业最标准的落地范式。1. 核心字段设计字段名类型存储内容作用权限控制mobileVARCHAR(64)11位手机号全号 AES-256/SM4 密文唯一真实存储用于发短信、登录校验等需要完整手机号的业务仅核心服务可解密禁止直接暴露给前端/后台mobile_maskVARCHAR(16)脱敏后的展示字符串如 138****8000纯展示用所有页面、接口直接返回该字段无特殊权限可公开展示mobile_last4CHAR(4)明文尾号4位建立普通索引用于按尾号快速查询、风控拉黑、运营筛选仅授权后台接口可访问全程记录操作日志2. 设计优势✅完全合规核心手机号全量加密存储满足个保法和等保要求拖库无明文泄露风险✅性能最优mobile_last4 建立索引后按尾号查询是 O(1) 的索引查询百万级数据毫秒级返回✅维护简单写入时一次性生成三个字段无需额外维护关联表一致性有保障✅风险可控仅后 4 位明文无法反推完整手机号配合操作审计和权限管控隐私风险极低面试官必追问环节层层深入追问1为什么只存尾号4位明文不存前3位或者更多前 3 位是号段包含运营商和归属地信息如果和尾号 4 位同时泄露会大幅缩小手机号的枚举范围比如 138 开头 尾号 8000全国只有约 10000 个可能。而单独的尾号 4 位全国有 10^4 10000 个相同尾号的手机号无法定位到具体个人隐私风险可以忽略不计。追问2如果需要按完整手机号精确查询用户怎么办我们会对完整手机号做一次AES-256 可搜索加密Searchable Encryption先生成 mobile_token 字段并建立唯一索引。查询时先用同一个加密密钥对输入的手机号计算 token然后用 token 值去数据库精确匹配匹配成功后再解密 mobile 字段使用。如果对安全性要求更高也可以采用慢哈希bcrypt/argon2 密文索引的方案权衡查询性能和安全强度。这样既保证了查询性能又不会在数据库中存储明文手机号。追问3尾号明文会不会有隐私泄露风险怎么规避风险极低但我们会做三层防护权限隔离只有运营和风控岗位的特定人员才能访问 mobile_last4 字段普通员工看不到操作审计所有对 mobile_last4 的查询操作都会记录日志包括查询人、查询时间、查询条件频率限制对按尾号查询的接口做严格的频率限制防止批量枚举攻击追问4如果未来需要支持按手机号前几位模糊查询怎么扩展这种需求非常少见而且风险很高。如果确实有必要我们会引入可搜索加密技术Searchable Encryption或者隐私计算方案绝对不会存储任何额外的明文片段。对于普通业务我们会建议产品调整需求改用其他非敏感字段查询。面试加分金句技术设计永远是安全和业务的平衡。全加密虽然最安全但会让业务完全无法使用全明文虽然方便但严重违规。而全号密文尾号索引的方案用最小的隐私代价解决了最大的业务痛点这也是它能成为行业标准的原因。