做企业系统集成的人，基本都绕不过短信这一关。无论是OA里的审批提醒、ERP里的库存预警，还是网站上的验证码登录，短信API都是最成熟、成本最低的方案。我这些年帮不同的业务系统对接过好几家短信服务商，踩过的坑不少，从签名审核卡壳到回调数据丢失，再到测试环境好好的上线就报错，各种问题都遇到过。这篇东西我按“从零到一”的思路来写，把短信API嵌入OA、ERP或网站系统的完整步骤、关键参数、常见坑位都过一遍，适合正在做集成开发的工程师，也适合刚接手这类任务需要快速上手的同学，哪怕你之前完全没碰过短信接口，照着做也能把链路跑通。

1. 先搞清楚需求：短信在业务系统里到底解决什么问题

1.1 短信和站内消息、App推送的本质区别

很多业务方一开始会问：我们已经有站内消息了，也有企业微信或者钉钉通知，为什么还要接短信？这个问题的答案其实藏在“触达率”三个字里。站内消息只能覆盖登录系统的人，App推送则完全依赖用户是否安装了客户端、是否允许通知权限，企业IM工具虽然触达率不错，但很多客户、供应商、外勤人员根本不在你的组织架构内，你没法强制他们装一个内部App。

短信是唯一一种不需要对方安装任何东西、不需要对方在线、甚至不需要对方有智能手机就能触达的方式。只要是手机号，就能收到，而且短信的打开率虽然比不上微信聊天，但在“系统通知”这个场景下，它的权威性和及时感是其他渠道替代不了的。尤其是一些关键节点的通知，比如财务付款结果、服务器报警、订单异常，业务方要的是“一定能收到”，而不是“大概率能收到”。

1.2 典型业务场景盘点

我梳理了几个最常见的短信接入场景，你可以对照自己的系统看属于哪一类：

不同场景对短信通道的要求完全不一样。验证码类必须保证极致速度，最好走专用通道；营销通知类对价格敏感，可以用营销通道，但营销通道普遍有频控限制，到达率也略微逊色；运维监控类的短信量不大，但必须极度可靠，甚至需要双通道冗余。这些差异在选型阶段就要想清楚，否则接完再换服务商，迁移成本远比你想象得高。

1.3 集成前先回答这几个问题

我在接一个新项目时，不管业务方催得多急，都会先拉着相关负责人把下面这几个问题过一遍：

第一，短信量级预估。每天是几十条还是几万条？这直接决定你选按量付费还是套餐包，也决定是否需要做本地队列缓冲。第二，是否需要状态报告。状态报告就是短信最终送达的结果，比如“已送达”“已失败”。如果只是发个内部通知，不一定要回调；但如果是验证码或者通知客户的订单信息，状态报告必须接，不然用户收不到短信你根本不知道。第三，发送方是系统自动还是人工触发。自动触发要考虑频控和防刷，人工发送则要考虑后台管理界面怎么做得简单易用。第四，预算上限。短信再便宜，量大了也是一笔不小的开销，需要提前设定一个企业级预算阈值，防止异常代码把短信费刷爆。

这几个问题不解决，后面选什么服务商、用什么签名、怎么设计代码结构，全都没法定。我遇到过不止一个项目，因为前期没确认量级，选了不适合的套餐，结果上线一周短信费就超了预算五倍，最后紧急改方案，折腾得够呛。

2. 选型准备：服务商、签名、模板一个都不能少

2.1 服务商选型的核心指标

短信服务商现在很多，价格也卷得很厉害，动辄宣传“几分钱一条”。但选服务商绝对不能只看单价，我建议至少从六个维度横向比：到达率、延迟、稳定性、审核效率、技术支持、API文档质量。

到达率听起来很抽象，实际上同一个服务商在不同运营商、不同地区的到达率差异不小，你可以让厂商提供近三个月的整体到达率统计，低于95%的直接排除。延迟指的是从你调用接口到用户收到短信的时间，正常要在3秒内，超过5秒的体验就很差了。稳定性主要看是否有成功率的SLA承诺，以及是否有多通道备份。审核效率影响的是签名和模板的上线速度，有的厂商上午提交下午就过，有的能卡你三天。技术支持这块，24小时工单响应和有人拉群陪跑完全是两种体验。API文档就更直接了，文档写得糊弄的厂商，后续联调你大概率会吐血。

我当时对接的一家厂商，价格确实便宜，结果文档里连签名计算的示例代码都是错的，我照着抄都报验签失败，找客服反馈了两轮才更新文档。这种隐性成本，比省下来的那几分钱贵多了。

2.2 签名申请：看起来简单实际很容易被驳回

短信签名就是短信正文前面那个【】里的内容，比如【某公司】。签名的核心作用有两个：一是告诉用户你是谁，建立信任感；二是过运营商的内容审核。没有签名的短信基本是发不出去的，或者会被手机系统直接拦截。

申请签名时最容易踩坑的是资质材料。企业签名要提供营业执照，而且签名内容必须和公司名称或品牌相关。比如你公司叫“某某科技有限公司”，申请签名“【某某科技】”基本能过，但你想申请“【小助手】”这种就很容易被驳回，除非你能提供对应的商标注册证或软著证明。签名驳回之后不是改个名字重新提交就行，很多服务商对驳回次数有限制，反复驳回可能影响账号信誉。

我自己的经验是，申请前先去服务商后台看签名审核规范，两个以上汉字的签名必须准备对应资质。如果你有几个不同的业务线，最好是各自申请不同的签名，比如“【某某科技】”用于公司整体通知，“【某某App】”用于App验证码，这样即使某个签名被投诉封禁，其他业务还能继续发。

2.3 模板变量的正确写法

模板是短信正文的格式定义，比如“您的验证码是${code}，5分钟内有效”。你发短信时传的变量值会替换掉模板里的占位符。模板最容易出问题的不是内容本身，而是变量设计。

关键点在于：变量要独立、语义清晰、且内容尽量可预期。比如“${userName}”里面如果传了带有特殊字符的内容，比如“张三%%%”，就可能触发运营商的拦截规则。中文变量、表情符号、特殊标点、超长字符，都是在模板审核阶段容易被拒的雷区。另外，模板里不要放网址链接，运营商对链接审核极严，尤其是短链接，基本过不了；即使能过，也很容易被用户手机拦截。如果确实需要放链接，优先选择你自己备案过的完整域名。

2.4 对接前要准备的三样东西

正式写代码之前，你手头要备齐三样东西：API密钥（一般是AccessKeyId和AccessKeySecret）、签名名称、模板Code（模板ID）。这三样缺一样都没法在联调环境里发出第一条短信。

API密钥管理是个老生常谈但很多人会犯的错。AccessKeySecret就是短信服务商的“密码”，它一旦泄露，别人就能拿你的账号刷短信，轻则短信费用爆掉，重则账号被停用、签名被封。所以密钥一定要放服务端环境变量或配置中心，绝对不要写在前端代码里，也不要在代码仓库里明文存储。我见过某个项目把AccessKeySecret直接写死在JavaScript文件里，用户一打开浏览器控制台就能看到完整密钥，当天晚上账号就被盗刷了几百块钱的短信通道费用。

另外，IP白名单一定要开。服务商一般支持配置只允许特定服务器IP调接口，加上这个限制之后，即使密钥泄露，攻击者也没法从别的机器发起请求，这是短信API集成的第一道安全防线。

3. 接口调用核心：签名、参数、回调全拆解

3.1 一个标准短信发送接口的请求长什么样

不同服务商的短信API具体格式略有差异，但主流的HTTP接口都遵循同一个风格：REST风格或表单POST调用，参数包括接收手机号、签名、模板、模板变量、以及一串用于身份校验的签名值。我拿一个常见的POST接口示例来说明，域名和参数格式是行业通用的形式，你在对接任何一家服务商时，只需要照着你那家文档的字段名做映射。

POST https://sms.example.com/v2/send Content-Type: application/x-www-form-urlencoded accessKeyId=LTAI4XXXXXXXX phoneNumbers=13800138000 signName=%E3%80%90%E6%9F%90%E5%85%AC%E5%8F%B8%E3%80%91 templateCode=SMS_123456 templateParam={"code":"382910","product":"demo"} timestamp=2025-01-01T12:00:00Z signature=Base64(HMAC-SHA256(secret, content))

这个接口做的事情就是告诉服务商：帮我把这条短信内容发给指定手机号。你可能会问，短信内容在哪？其实内容不在请求里，服务商是根据signName（签名）和templateCode（模板）去后台拼装短信内容的，templateParam只是填进模板的变量。这也解释了为什么模板审核那么严格——因为实际发出的内容是由服务商拼接的，服务商需要对内容合规负责。

3.2 签名计算：最常见的报错源头

这里的“签名”和2.2里说的短信签名【某某】是两个完全不同的概念。接口签名是为了验证“调用者确实是账号的合法持有者”而生成的一串哈希值。这个环节是联调时报错的重灾区，十次报错里至少有八次是签名问题。

签名计算逻辑通常是：把请求参数按字典序排序，拼接成待签名字符串，加上AccessKeySecret，用HMAC-SHA256算法计算，再Base64编码得到签名值。这里有几个细节特别值得注意：第一，排序必须是严格的字典升序，包括URL编码后的字符；第二，URL编码时要注意空格编码成“%20”而不是“+”，很多语言的标准库在这一点上行为不一致；第三，拼接的所有参数都要参与签名，连timestamp也不能漏；第四，签名用的AccessKeySecret和生成AccessKeyId不是同一个东西，别搞混。

给你看一段Java的示例代码，这是生产环境中我用过很多次的标准写法，踩过坑之后总结出来的：

public class SmsSigner { public static String sign(Map<String, String> params, String secret) throws Exception { // 1. 参数按字典序排序 String[] keys = params.keySet().toArray(new String[0]); Arrays.sort(keys); // 2. 拼接待签名字符串 StringBuilder sb = new StringBuilder(); for (String key : keys) { if (params.get(key) != null && !params.get(key).isEmpty()) { sb.append(key).append("=").append(encode(params.get(key))).append("&"); } } String stringToSign = sb.substring(0, sb.length() - 1); // 3. HMAC-SHA256计算 Mac mac = Mac.getInstance("HmacSHA256"); SecretKeySpec keySpec = new SecretKeySpec(secret.getBytes(StandardCharsets.UTF_8), "HmacSHA256"); mac.init(keySpec); byte[] result = mac.doFinal(stringToSign.getBytes(StandardCharsets.UTF_8)); return Base64.encodeBase64String(result); } }

3.3 发送接口的响应解析

发送接口调用成功并不代表短信已经发到用户手机上了，它只代表服务商“受理”了这条发送请求。这就像你往邮筒里投了一封信，邮筒收取成功不等于收件人一定读到了信。所以响应体里通常有两层信息：请求层的业务状态码和发送层的消息状态。

以常见的响应格式为例：

{ "Code": "OK", "RequestId": "16A96B9A-F253-4F6C-8A4E-1234567890AB", "BizId": "123456789012345678" }

Code为OK表示请求被受理，BizId是这条短信的唯一业务标识，后面查状态报告要用。Code不是OK的情况就要对照服务商提供的错误码表排查，常见的错误比如缺少参数、签名无效、模板不存在、手机号格式不对等。一定要把RequestId和BizId记到日志里，这是你后续找服务商排查问题的凭据。

3.4 状态报告：用回调别用轮询

短信发出后到底到没到？移动、联通、电信会把到达状态回传给服务商，服务商再通过状态报告接口推给你。状态报告就是这条链路里的“回执”。

很多第一次接短信API的同学会问：我能不能主动查询？答案是可以，但强烈不建议用轮询代替回调。轮询不仅浪费请求次数，而且查询接口返回状态有一定延迟，做不到实时。正确的做法是：提供一个回调接口给服务商，服务商在收到运营商回执后，以异步HTTP请求的方式推送给你的系统，你再把BizId对应的记录状态更新到数据库。

回调接口要注意两个点：一是验签，服务商推送的回调请求里同样带着签名，你必须验证签名后才更新本地数据，否则任何人都可以伪造回调把你的短信状态改成“已发送”；二是幂等，回调有可能重复推，同一BizId的状态更新要做去重处理，不能因为推了两次就把业务状态翻来覆去地改。我的习惯是拿BizId加上状态类型做联合唯一索引，重复回调直接忽略。

4. 嵌入OA、ERP、网站的完整实操路径

4.1 代码分层：短信模块不要散落各处

很多项目接短信时最典型的坏味道，就是在OA的审批代码里直接拼一个HTTP请求，在ERP的预警代码里又复制粘贴一份，在网站的验证码逻辑里再写第三份。散落的短信代码会导致三个严重问题：密钥重复存储、服务商切换时改动量巨大、参数配置不一致。我的建议是抽象一个独立的短信服务模块，不管你的系统是微服务还是单体架构，都让业务代码只依赖这个模块的接口。

这个模块的职责划分我通常这样定：最底层是发送封装，只做一件事，就是把参数拼好、算好签名、调HTTP接口；中间层是发送策略，决定走哪个通道、是否需要延迟发送、失败是否重试；最上层是业务模板映射，把“审批通过通知”这样的业务动作映射到具体的签名和模板Code上。业务方想发短信，只需要调用一个方法，传入手机号和业务参数，完全不关心底层实现。

4.2 异步发送与重试机制

短信发送的耗时通常在几百毫秒到几秒不等，如果业务接口同步等待短信返回，会拖垮整个接口的响应速度。举个例子，用户在网站上点击“获取验证码”，如果发送短信本身耗时两秒，再加上网络波动，用户可能要等三秒以上才看到“已发送”的提示，这个体验就很差了。

正确的做法是在短信模块内部做异步化。业务接口把短信请求丢进内存队列或者消息队列后立即返回，短信模块由独立的工作线程消费队列里的任务，调用短信API。我这里给一个Java的简单异步实现思路：

@Component public class SmsSendService { private final ExecutorService executor = Executors.newFixedThreadPool(8); public void sendAsync(SmsRequest request) { executor.submit(() -> { int maxRetry = 3; for (int i = 1; i <= maxRetry; i++) { try { SmsResponse response = send(request); if (response.isSuccess()) { return; } } catch (Exception e) { log.error("短信发送失败，第{}次重试", i, e); } Thread.sleep(500L * i); } }); } }

注意几点：线程池大小要根据短信量和服务商限流策略来定，建议初始值不要超过10；重试要有退避策略，第一次失败等0.5秒再试，第二次等1秒，不要死循环；重试次数限制在2到3次就够了，超过3次再重试意义不大，不如走失败告警人工介入；最关键的一点，要对同一业务实体的发送做去重，比如同一用户短时间连续点击“获取验证码”，只允许前一条发送失败后才有第二条，防止并发循环内重复发。

4.3 通道开关与配置中心

短信发送是强依赖外部服务的能力，而外部服务总会出问题：服务商宕机、密钥被禁用、余额不足、运营商大面积拦截。所以在设计短信模块时，一定要预留“开关”和“降级”能力。

最基础的是一个全局开关：true表示正常发送短信，false表示直接跳过发送但业务逻辑照常走，只记录日志。这个开关一定要做成运行时可以动态修改的配置项，放到配置中心或者数据库缓存里，不要写在代码里改完还要重新发布。我在一个项目里就靠这个开关扛过一次事故：某服务商因为运营商策略调整，短信接口大面积超时，业务方的下单链路被拖慢了百分之三十。我当场把短信开关关闭，下单接口立即恢复，等服务商恢复之后再打开开关，把积压的队列任务消化掉，整个过程没发一次版本。

除了全局开关，还建议做通道级配置。比如验证码走通道A，营销通知走通道B，单独把通道A停掉不影响通道B。短信模块的配置项不要写死在Serverlet容器里，统一走配置中心管理，这样运维和开发都能在界面上调整，不用登录服务器。

4.4 OA场景：审批通知怎么接

OA系统里的短信需求非常典型，最常见的是“审批结果通知”。比如员工提交请假申请，流程结束后负责人通过了，系统自动给员工发一条“您提交的请假申请已通过”。这个场景的集成逻辑并不复杂，难点在于触发点的选择。

我的建议是把短信触发点和流程引擎的“结束节点”绑定，而不是和某个具体的操作方法绑定。很多OA系统是流程引擎驱动的，同一个流程可能有多个分支，如果只在某一个分支的代码里发了短信，其他分支就会漏发。正确做法是在流程状态机进入“完成”状态时统一触发通知，根据审批结果类型映射不同的模板，比如通过、驳回、转交、撤回分别对应不同文案。通知里尽量带上审批单号和申请时间，这个信息对用户很重要。

还有一个经验是，OA的审批通知最好带“操作链接”，但如果模板加不了链接，至少要把单号带全，让用户能在OA里搜到这条单。短信文案要简洁，说清楚“什么事、什么结果、什么时候”，别写又长又绕的客套话。

4.5 ERP场景：库存预警与订单提醒

ERP系统的短信需求往往更紧急性，比如库存量低于安全线、客户订单超时未发货、供应商交期延迟。这些事件一旦发生，影响的是业务连续性，所以短信通知必须可靠，而且要能区分通知对象。

库存预警这个场景我拆过不少案例，核心设计思路是阈值加去重。系统每隔一段时间检查库存，发现低于预警值就发短信给采购负责人。如果库存一直低，每分钟检查一次就每分钟发一次，那采购负责人会被短信轰炸到崩溃。所以一定要做去重：同一个物料在同一个预警周期内只发一次，只有当库存继续下跌超过更严重的阈值时，才发升级警报。这个规则用数据库里的发送记录表就能实现——记录物料编码、预警级别、发送时间窗口，下次检查时发现同一窗口内已经发过就跳过。

订单提醒类还要考虑时区因素。ERP系统如果服务的是全国甚至跨境的业务，晚上十点给客户发“订单发货”通知可能不太合适，最好把发送时间窗口做成配置，非工作时间段的通知走队列延迟到第二天早上发。这虽然不影响短信通道本身，但用户体验差别非常大。

4.6 网站场景：验证码与登录安全

网站接入短信API最常见的场景就是注册和登录验证码。验证码类短信对安全和时效的要求最高，集成的细节也比普通通知多。

第一，验证码必须有时效。一般是5分钟内有效，之后作废。这需要你在服务端存储验证码及其过期时间，而不是只在短信里告诉用户。第二，要有发送频率限制。同一手机号60秒内只能发一次，同一IP一天内发短信的次数也要限，否则会被恶意刷短信，消耗你的费用。这是我说的“防刷”关键手段，一般在网关层直接拒绝超频请求，状态码给429。第三，验证码内容必须随机且不可预测，用安全随机数生成，不要用时间戳做种子。

登录验证码的代码流程大概是：前端输入手机号发起请求，后端先做频率校验，通过后生成6位随机码，存入Redis设置5分钟过期，然后调短信模块发送，前端跳转验证码输入页。用户提交验证码时，后端从Redis读取比对，同时做一次性消费（无论验证成功还是失败，验证码都要作废），防止重放攻击。这套流程我已经在很多网站上实践过，稳定可靠。

还有一个细节需要提醒：网站在海外有用户的话，要确认短信服务商支持国际短信，并且手机号E.164格式要处理对。国家码、区号、本地号码的拼接在前后端都要做校验，不然海外用户永远收不到验证码。

5. 常见问题与排错实录

5.1 签名报错：sig参数校验失败

签名校验失败是最常见的联调期问题，报错信息通常是“SignatureDoesNotMatch”或者“InvalidSignature”。排查思路基本固定：先确认你代码里参与签名的参数集合和请求中实际的参数集合完全一致；再确认参数编码方式统一，特别关注中文字段被URL编码后的空格处理；然后确认没有遗漏参数，比如有些服务商要求对请求时间戳也参与签名；最后确认密钥用的是AccessKeySecret而不是AccessKeyId。

很多人在联调时用Postman直接测接口，测通了再往代码里搬，这时候容易踩一个坑：Postman的签名插件和你代码里的签名实现可能对参数排序的规则不一致。比如Postman工具自动帮你做了URL解码，你代码里没有，两边算出来的签名就永远不一样。我的建议是，第一优先用服务商提供的SDK做签名，不要自己造轮子；如果必须自己写，就严格按照服务商的示例代码来，一门语言一门语言地对照，不要照着A语言的写法去写B语言。

5.2 模板变量非法与审核驳回

“变量内容包含非法字符”这一类的报错，几乎都是模板变量传值不规范引起的。最典型的是手机号模板里传了一个带特殊符号的变量，或者验证码模板的变量传了一个汉字。运营商的内容审核系统非常机械，它不关心你的变量语义，只检查最终拼接出来的短信内容是否包含敏感词、是否符合格式约束。

解决思路有两个：一是规范入口，在业务系统里对所有传入短信模块的变量值做清洗和校验，不符合规则的直接拒绝或替换；二是规范化模板，把容易变化的文本尽量放到服务商后管配置，不要通过变量传。比如“欢迎您注册，账号 ${account} 已开通”这句文案，把“欢迎您注册”硬编码进模板，不要通过变量传入，这样审核通过率会高很多。模板一旦被驳回，修改后要重新审核，这期间的短信发送会全部失败，所以模板文案在提交前就要仔细过一遍，别抱着“先提交试试，被驳回了再改”的心态。

5.3 限流与并发控制

短信服务商为了保障通道稳定，都会限制单位时间内的请求量，比如“每秒最多100条”或者“每分钟最多5000条”。你的业务系统如果发送量超过阈值，服务商就会返回限流错误码。设计短信模块时，一定要内置本地的流量控制机制。

最简单的做法是令牌桶或信号量。信号量的实现思路是：在短信模块内部维护一个计数器，初始值等于最大并发数，每个发送任务执行前acquire一个许可，执行完成后release。这样即使业务方疯狂调用短信接口，真正打到服务商那里也会被限制在安全水位。限流还涉及队列的处理：当限流发生时，建议把请求缓存起来延迟重试，而不是直接丢弃。比如ERP批量补发通知时，一次性有几千条要发，本地队列加上限流配合，可以做到一条不丢地慢慢消化，而不是一拥而上全被服务商拒掉。

5.4 回调丢失与乱码处理

状态报告回调丢失是我在生产环境里遇到过的最头疼问题之一。明明用户已经收到短信了，数据库里的状态还是“发送中”，导致用户误以为短信没发出去。排查下来发现，服务商推送回调时，我们的回调接口偶发超时，服务商重试两次后放弃，状态就丢了。

应对措施我总结为三个：第一，回调接口要做成轻量级，只做验签和落库，不要在里面触发其他业务逻辑，更不能在回调里同步发新的短信，那会串联故障。第二，回调接口不要做耗时长的数据清洗和建模，直接写入消息队列，由消费者异步更新状态。第三，即使回调链路做到了以上两点，也要有一个兜底任务，定时去服务商查询某个时间窗口内“发送中”的短信，把状态补齐。兜底任务小时级跑一次就够了，不等同于前面说的轮询方案。

乱码问题通常出现在发送中文内容的场景。排查方向很明确：检查请求的Content-Type是否声明了UTF-8、URL编码是否使用了UTF-8、模板变量传入时是否经过了乱码前的编码转换。排查乱码最笨也最有效的方法，是用日志把最终拼装好的字符串打出来，看到底是哪个环节引入的乱码。

5.5 线上故障快速降级

最后聊一个很多系统设计会忽略的环节：短信API挂了之后的降级策略。短信服务商虽然是商业级的，但并非永不故障。我经历过一次服务商全链路故障，持续了一个多小时，所有通过它发的短信都超时。如果当时没有降级方案，我们自己的核心业务流程会跟着一起瘫痪。

降级方案根据业务场景有不同做法。验证码类短信降级时，可以考虑把验证码通过备用通道发送，或者在页面上提供语音验证码甚至客服人工验证兜底；纯通知类短信降级时，则可以先退化为站内消息或邮件，等服务商恢复后再补发。降级逻辑放在短信模块内部统一实现，业务方无感知。

这里要特别提醒：备用通道要提前接，不要等故障发生了再去临时注册一家服务商。因为备用通道的签名、模板都需要审核，临时接是绝对来不及的。我建议至少保留一家不同云厂商的备用通道，每一两个月手动发一条测试短信，确认备用通道依然是通的。这条成本很低，但能救命。

6. 最后分享一点实际经验

做了这么多年系统集成，短信API的对接逻辑其实谈不上复杂，真正的复杂度都在细节里：签名计算的一处编码不一致，就能让你多排查半天；模板变量里的一个特殊字符，就可能触发拦截；回调接口的一次超时，就会让一批用户看到错误的发送状态。这些坑没有一个能靠背八股文避开，都得在真实现场里踩过才能记住。

我个人最深的体会是，短信模块一定要做成一个独立、完整的服务组件，而不是散落在业务代码里的几次HTTP调用。它要有自己的配置管理、限流策略、重试机制、状态存储、降级开关和日志体系。这样做的好处，短期看是接入简单，长期看是当你需要调整通道、切换服务商或者处理故障时，不至于手忙脚乱地去改几十个页面。

如果你正在做的系统还没有接短信，我建议从最小的场景切入，比如只接一个验证码功能，把整条链路跑通之后，再逐步扩展到审批通知、库存预警。先跑通再优化，比一开始就想做一个大而全的短信平台要实际得多。等你接完第一个场景之后，再回来看这篇文章里的其他坑位，相信我，你会感谢当初折返跑的那些晚上。