大厂高频面试题：手机号加密存储后，如何快速按尾号查询?
面试官："在你的项目中，用户手机号是怎么存储的？我们都知道手机号属于敏感个人信息，必须加密存储。那如果现在有一个需求：运营后台需要支持按手机号尾号4位快速筛选用户，同时还要满足《个人信息保护法》和等保2.0的合规要求，你会怎么设计？"
常见错误回答（踩坑点）
- ❌ "把密文解密后，在内存里过滤尾号"
- 问题：百万级以上数据直接 OOM，性能灾难，完全不可用
- ❌ "用 LIKE '%xxxx' 直接查密文字段"
- 问题：AES/SM4 加密后是随机字符串，密文尾号和明文尾号没有任何关系，查不到任何结果
- ❌ "只加密中间 4 位，首尾明文存储"
- 问题：严重不合规，数据库拖库后直接泄露完整手机号，现在没有任何大厂会这么做
- ❌ "单独建一张尾号映射表，存尾号和用户 ID 的关系"
- 问题：冗余度高，维护一致性麻烦，不如直接冗余字段高效
标准满分回答（大厂通用方案）
"我会采用全号密文 + 脱敏展示冗余 + 尾号明文索引的三字段设计方案，这也是目前国内互联网行业最标准的落地范式。
1. 核心字段设计
字段名 | 类型 | 存储内容 | 作用 | 权限控制 |
mobile | VARCHAR(64) | 11位手机号全号 AES-256/SM4 密文 | 唯一真实存储，用于发短信、登录校验等需要完整手机号的业务 | 仅核心服务可解密，禁止直接暴露给前端/后台 |
mobile_mask | VARCHAR(16) | 脱敏后的展示字符串（如 138****8000） | 纯展示用，所有页面、接口直接返回该字段 | 无特殊权限，可公开展示 |
mobile_last4 | CHAR(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）或者隐私计算方案，绝对不会存储任何额外的明文片段。对于普通业务，我们会建议产品调整需求，改用其他非敏感字段查询。"
面试加分金句
"技术设计永远是安全和业务的平衡。全加密虽然最安全，但会让业务完全无法使用；全明文虽然方便，但严重违规。而全号密文+尾号索引的方案，用最小的隐私代价，解决了最大的业务痛点，这也是它能成为行业标准的原因。"