使用SMS Retriever API时iPhone显示短信哈希的解决方法

SMS Retriever API对短信格式的强制校验规则仅包含三点，并未要求哈希串必须紧跟验证码正文：

1. 短信起始位置必须包含<#>标识（部分区域运营商可替换为[#]，不影响识别效果）
2. 单条短信总长度不超过140字节，避免被运营商拆分为多条导致识别失败
3. 短信末尾必须完整包含连续的11位应用哈希值

基于以上规则，以下是经过生产环境验证的可行方案，完全可以兼顾Android端自动读取能力和iOS端用户体验：

• 通用低成本方案：正文与哈希串之间插入足量换行+弱提示
  写完验证码正文后，连续插入8-10个换行符，再放置哈希串，哈希串前补充一句极短的提示如「系统识别码 无需理会」即可。
  iOS系统的短信会话列表默认仅展示短信前2行内容，用户进入短信详情页后首屏也只会显示验证码正文，必须主动下滑到最底部才能看到哈希串，绝大多数用户不会滑动到该位置，几乎不会对体验造成影响。同时该格式完全符合API识别规则，Android端自动读取成功率不会出现损耗。
  调整后的短信格式参考：

  <#>您的验证码为123456，5分钟内有效，请勿泄露。
  
  
  
  
  
  
  
  
  
  系统识别码 He42w354ol9
  

  注意提前核算短信字节长度：单个换行符占1字节，提示文本控制在10个汉字以内即可保证总长度不超过单条短信阈值。

• 最优体验方案：客户端上报设备类型做短信内容分流
  在用户点击「获取验证码」按钮时，由客户端主动上报当前设备类型，服务端将手机号与对应设备类型做5-10分钟的临时缓存，发送短信时根据缓存内容拼接格式：对Android设备发送符合API要求的带哈希版本，对iOS设备发送纯验证码正文版本。
  注意需要做兜底逻辑：如果缓存不存在/已过期，统一发送上述带换行弱提示的通用版本即可，避免用户换设备收验证码时出现兼容问题。不要依赖手机号号段、UA等非客户端上报的特征判断设备类型，这类方案准确率极低，容易出现识别错误。

避坑提醒：不要尝试在哈希串中插入不可见字符、或拆分哈希串穿插在正文内容中，这类操作会直接导致Android端SMS Retriever API识别失效，哈希串必须以连续11位字符的完整形式出现在短信末尾。

内容的提问来源于stack exchange，提问作者Thomas Ramé