短信
它到底能做什么
凭据，加密存储
你的 Twilio SID 和令牌加密存储，之后再也不会显示出来；你的发送方标识、Messaging Service 和各项注册，都保持你当初设置的样子。
货真价实的双向
入站短信通过经过加密签名的 Webhook 到达，并作为已分流的会话落地；状态回调让每条消息沿着只进不退的“已发送 → 已送达”阶梯往上走——已确认的送达绝不会倒回去。
分段数就写在会话里
每次发送都会记下实际发出去了几个短信分段——你的 Twilio 账单，在会话里就能解释清楚。
验证是内置的
一次性验证码的手机验证走 Twilio Verify——验证码由 Twilio 生成、投递和校验；我们什么都不存。
技术细节
分段算法就是钱——所以它住在服务端
成本只有一个事实来源
分段计数跑在服务端，而且只有一处实现。在客户端放一份副本，一定会和真实账单产生偏差——而偏差的方向，永远是让人安心的那一边。
那个让账单翻三倍的 ş
只要有一个字符落在 GSM 字母表之外，整条消息就掉到 70 字符一段。编辑器在你发送之前就知道这件事——161 个 GSM 字符要花两个 153 的分段，而不是 160 加 1。
连转义对也一并算上
像 ^、{、} 和 € 这样的字符，在 GSM 编码里每个占两个单位，emoji 在 UCS-2 里也占两个——计数器按运营商的算法来收。
优先走 Messaging Service
当你配好了 Twilio 的 Messaging Service，发送会优先走它，而不是走一个裸号码——继承你的号码池、粘性发送方和合规配置，而不是绕过它们。
Verify，托管着来
手机验证用的是 Twilio Verify：验证码由 Twilio 生成、投递和校验，并按客户的语言本地化——没有 OTP 密钥要存，也没有验证码会泄漏。
失败会带着名字回来
一次被拒的发送，会带着 Twilio 真正的原因返回——鉴权、地区权限、未验证的试用号码——直接呈给操作的人，而不是被洗成一句笼统的报错。
接入设置
连接方式
粘贴凭据
SID 和令牌，静态加密存储，配置时就验证一遍。
挑选发送方
你的号码和发送方标识会以渠道的形式出现，可以按部门分流。
带着刹车发短信
营销活动在发送的那一刻按收件人逐个检查同意——周二退订的人，周三就会被跳过，并连同原因一起记录下来。
安全与保证
无聊但管用的保证
入站在密码学上归你
每一个入站 Webhook 都用 Twilio 的签名方案校验——对完整 URL 和排序后的载荷做 HMAC，密钥就是你的账号令牌。一个未签名的“入站短信”，是通往别人收件箱的一扇敞开的门；这一扇是关着的。
密钥当密钥对待
SID 和令牌静态加密存储，只出现在鉴权头里，绝不写进日志，也绝不回显到报错信息中。
同意，查两遍
营销活动在搭建受众时查一遍同意，发送每条消息时再查一遍——周二退订的人，周三会被跳过，跳过这件事会连同理由一起记录下来。
连回执都带签名
送达状态回调和入站消息一样做签名校验，用的是你自己的密钥——一个未签名的状态端点，等于让任何人都能把你的消息标成“已送达”，这比一条假消息更安静，也更糟，因为根本没人会去查。
不加粉饰的细则
边界，写清楚
不支持彩信
图片消息没有实现——带附件会以一个具名的理由失败，而不是被悄悄丢掉，但它确实会失败，我们照直说。
字母数字发送者 = 单向
一个带品牌名的短信发送方收不到回复——这是短信的物理规律，编辑器知道这一点。