简介：《短信发送流程学习教案》是一份面向通信专业学生、网络运维或计费相关人员的专业资料，以PPT形式系统梳理短信从发送到接收所涉及的核心信令流程。教案共1个pptx文件，压缩包约158KB，内容精炼；随附8页流程图与分步编号，覆盖漫游用户MO、省内互通MO、省内/漫游/省外用户MT以及本地/异地互通短信MT等典型场景，以BSC、MSC、LSTP/HSTP、SMSC等网元为主线，清晰标出每一步的信令走向和应答关系。已有67人学习下载，适合课堂讲解、自学入门或日常排错参考。借助这些图示，学习者可快速理清MSC、LSTP/HSTP、SMSC、HLR、ISMG等网元间的协作关系，理解短信中心号码鉴权、用户归属查询、计费话单生成等关键环节。这对运营商技术人员优化通信服务、高校学生理解信令过程，以及日常排查短信无法正常传输的问题，都能提供直观而实用的抓手。

1. 短信发送流程学习教案：比想象中更需要一份完整的链路图

很多团队做短信发送，第一反应是“调个接口不就行了”。真正接手后才发现，从业务系统发出请求到用户手机弹出通知，中间隔着短信平台、运营商网关、通道调度、状态报告回传好几个环节，任何一个环节超时、丢包、限流，都表现为“用户没收到”。这份教案的价值，就是把这条链路从黑匣子拆成几个可以逐个讲解、逐个排查的模块，让新人不靠猜、不靠试错也能理解短信为什么发不出去、状态为什么对不上。适合给接手短信模块的初级开发做入职培训，也适合给运维和产品讲清楚短信送达背后的技术约束。我一般建议用两到三次分享课讲完，配套的实际业务系统流程图比PPT更重要，但PPT先把骨架立住。

2. 从业务系统到手机屏幕：短信发送流程的完整链路

2.1 四个环节一条链：谁在发、谁在传、谁在送、谁在收

短信发送流程表面看是“提交内容 → 收到回执”，实际拆开至少四个环节。

第一环是业务系统。订单通知、验证码、营销活动，这些触发动作都在业务系统里发生，产生的短信内容通过HTTP或SDK接口提交给短信平台。这一环的关键不是发送本身，而是业务系统对发送结果的预期管理——是同步等结果，还是异步轮询，决定了后面整个流程的设计。

第二环是短信平台。平台收到请求后做三件事：鉴权校验（账号、签名、模板是否合法）、内容审核（敏感词、违规词过滤）、路由分配（选哪家运营商通道、哪个通道优先级高）。平台返回的响应只代表“我收到了”，不代表“用户收到了”，这一点必须在教案第一页就讲清楚，否则学员会把平台的受理回执当成送达确认。

第三环是运营商网关。短信平台把内容转给三大运营商的行业网关，运营商负责实际的无线下发。这一环是真正的黑匣子，平台能做的只有等待状态报告。

第四环是用户手机。手机收到短信后，正常情况下会反馈“送达”状态给运营商，运营商再逐级回传，最终由短信平台通过状态报告推送给业务系统。整个链路才算闭环。

教案开篇不要急着讲接口文档，先把这四个环节画成一条横向泳道图，每个环节标注“能确认什么、不能确认什么”，学员对短信的不确定性就会有直观认识。

2.2 三张必须画进教案的流程图与各自的讲解要点

流程图画对了，教案就成功了一半。我建议在教案里固定画三张图，分别对应不同讲解场景。

第一张是主流程时序图，画业务系统、短信平台、运营商、手机四个对象，展示一次正常发送的请求、响应、状态报告回传。这张图讲的是“正常路径”，让学员建立标准模型，明确每个响应码的含义。讲的时候顺带强调短信平台的“受理成功”不等于“发送成功”。

第二张是异常分支图，把超时、失败、状态报告丢失、审核拒绝四条异常路径分别画出，标注每个异常发生后系统应该做什么。比如超时是重发还是标记失败，状态报告迟迟不来是主动查询还是静默等待，审核拒绝是回调通知还是丢弃。这张图要配合异常码表一起讲，学员才能把抽象异常和具体处理动作对应起来。

第三张是延迟队列重试图，展示一条短信从提交到最终成功或放弃的完整生命周期，包括重试次数上限、重试间隔、最终失败后的告警通知。这张图是教案里的进阶内容，直接对应生产环境最容易出问题的重试风暴场景。

这三张图是教案的核心资产，建议做成可编辑的源文件放在培训资料里，方便每次讲完根据实际业务调整。PPT翻页可以快，这三张图值得停下来反复讲。

2.3 为什么教案要先讲失败路径而不是成功路径

人有路径依赖，学员如果先入为主记住了“提交→受理→下发→送达”这条顺利路径，遇到实际问题时反而反应不过来。反过来，从失败路径切入，学员从一开始就带着“哪里会挂”的意识去看流程，效果会好很多。

我在实际培训里常用的切入方式是：先丢一个问题给学员——“用户反馈没收到验证码，你从哪几个环节排查？”让学员自己试着答，再逐步揭示答案。排查顺序应该从后往前：先确认用户手机信号和垃圾短信拦截，再查状态报告里有没有送达回执，再查短信平台日志里有没有下发记录，最后看业务系统有没有成功提交。这个排查链路的顺序和发送链路正好相反，教案里要把这两条线都画清楚。

另外，讲失败路径时顺带讲清楚各环节的超时阈值。比如业务系统调用短信平台的HTTP超时通常设3到5秒，平台等待运营商状态报告的回执超时通常按小时计，两套超时逻辑完全不同。很多线上事故就是业务系统用自己的超时逻辑去等状态报告，等不到就重发，结果造成重复发送。教案这一页要点透：等待时长和发送链路环节强相关，不能用一套参数通吃。

3. 设计教案前先定框架：面向谁讲、讲到多深

3.1 开发、运维、产品三个角色的知识点差异很大

一份教案不可能让三类人都满意，开讲之前必须先确认主要受众。开发关注接口协议、状态码、重试机制和数据一致性；运维关注通道健康度、限流阈值、告警规则和故障切换；产品关注送达率、到达时延、费用核算和用户投诉处理。

面向开发讲，教案要放真实的接口报文示例，包括请求头和请求体字段说明。面向运维讲，教案要放监控指标清单和告警规则模板。面向产品讲，教案要放送达率报表解读和常见投诉原因分析。我建议做成一份主体教案加三份补充材料的结构，主体讲通用链路，补充材料按角色拆分，各自拿回去看自己的部分。

这里有个常见失误：把开发向的接口报错码抛给产品看，产品看不懂，觉得培训没用；或者把产品向的送达率口径抛给开发，开发觉得不解决实际问题。教案里最好有明显标注，比如“下表仅开发关注”或“本节适合产品和运营”，避免讲课时带偏受众。

3.2 教案章节模板：从接口调用到状态报告回传的5步结构

一份能直接拿来培训的教案，我建议按下面5步结构组织内容，这也是我多轮迭代后比较顺手的结构。

第一步是链路总览，时长占整节课的20%。放四环节泳道图和正常时序图，目标是让学员记住“业务系统、短信平台、运营商、手机”这四层。

第二步是接口与协议，占30%。面向开发放真实接口报文，面向产品放提交参数说明。这一部分重点讲清楚提交接口、状态查询接口、状态报告推送接口三个接口的差别——很多人把查询接口和推送搞混，逻辑就从这里开始乱的。

第三步是状态机与回调，占20%。用一张状态流转表讲短信从提交到送达的中间状态，并强调状态报告是异步推送，不是接口返回。这是教案里最容易讲得拖沓的部分，建议直接给一张状态表，不展开讲每个状态的设计渊源。

第四步是异常与重试，占20%。结合异常分支图讲，重点内容包括超时设置、重试次数、重复推送场景下业务侧的幂等设计。

第五步是监控与排查，占10%。给一张监控指标清单和排查步骤模板，如果时间不够可以只做概述，但必须提及，防止学员学完只会调接口不会看问题。

这5步结构本身没什么新意，但胜在稳定，适合作为公司内部技术培训的默认模板。

3.3 每页PPT的构成原则：流程图在前、参数表在后、异常注解留白

很多人做技术培训PPT容易把页面堆满，一页里既要放流程图又要放完整参数表，结果学员什么都没记住。我的原则是每页只解决一个问题，一张图配一张表，最多加一个异常注解。

具体拆解，一页PPT可以由三个区域组成：顶部流程图，展示这一步在整体链路中的位置；中间参数表，列出该环节的关键参数和推荐值；底部异常注解，列出该环节最常见的2到3个异常现象。这个结构对应人的认知顺序：先看上下文、再看细节、最后记风险。

以“调用短信平台接口”这一页为例，流程图位置标注业务系统和短信平台之间的请求响应，参数表放appId、secretKey、templateId、content、signatureName五个字段，异常注解放推荐超时时间和常见鉴权失败原因。三个区域内容量刚好，既不会让新人觉得没有抓手，也不会让熟手觉得啰嗦。

这里也补充一个取舍：有些短信平台的原生接口字段非常多，包括扩展码、定时发送、回执类型等，不用全部放进教案正文，把这些次要字段放在附录里即可，正文只保留主流程会用的字段，否则PPT篇幅会被无关字段撑爆。

4. 短信发送流程里的核心状态与关键参数：教案的硬核章节

4.1 用一张状态流转表讲清提交、下发、回执三态

短信状态字段每个平台可能命名不同，但归纳下来无非三个大状态：提交态、下发态、回执态。教案里先统一讲解这三个状态，再让学员对照实际平台去映射字段名，比直接背某个平台的状态码表更通用。

提交态指短信平台已收到业务系统的请求，完成鉴权和审核，准备下发。此时状态可能是“提交成功”或“等待下发”。下发态指平台已把短信提交给运营商网关，运营商尚未回传最终结果。回执态指运营商回传了DELIVRD（送达）、UNDELIV（失败）或超时未知。这里有个容易混淆的点：有些平台的状态报告里只有回执态，学员会以为中间状态不存在，其实只是平台没有展示。

教案里建议直接放下面这样一张状态对照表，让学员对照各自实际接入的平台去补全字段名：

这张表同时覆盖了正常和异常状态，学员对着表就能知道每种情况下自己该干什么，不会傻等也不会乱重发。

4.2 超时、重试、并发、优先级：4组必须写在教案里的参数

讲完状态，紧接着讲参数。参数是短信发送流程教案里实操性最强的部分，我建议固定覆盖4组。

第一组是超时参数。业务系统调用短信平台接口的超时建议3到5秒，平台回传状态报告的等待超时则按15分钟到2小时设置。两组超时差异很大，教案里要单独列出，防止学员用同一套超时逻辑处理所有环节。

第二组是重试参数。业务侧的重试只针对“提交失败”和“接口报错”，不对“状态报告失败”盲目重发。重试次数建议2到3次，间隔用退避策略，比如第1次30秒、第2次5分钟、第3次30分钟。教案里要强调一个原则：重试解决瞬时故障，不解决永久失败，运营商回执失败的重发时间窗口很短，错过就放弃而不是无限重试。

第三组是并发参数。业务系统到短信平台的并发连接数不是越大越好，超出通道阈值会被限流。建议以短信平台返回的限流响应为准做本地排队，而不是硬顶并发。教案里给一个经验值：单通道初始并发建议不超过200TPS，实际以平台压测结果为准。

第四组是优先级参数。验证码类短信的优先级高于营销类，通道故障时优先保证验证码通道。教案里建议给出按短信类型划分的优先级模板，比如验证码P0、通知P1、营销P2，以便做通道容灾时快速决策。

这4组参数直接决定线上短信服务的稳定性，教案里建议每讲完一组就抛出一个实际案例让学员分析，巩固理解。

4.3 可复用的教案参数配置表：拿来改一改就能用

如果不想从零设计教案里的参数页，可以直接用下面这张配置表作为底稿，根据实际短信平台的能力做增删：

这张表我每次培训都会发给学员当参考，同时提醒一句：没有任何一组默认值能适配所有业务，表里的推荐值适合验证码和通知类短信，营销短信的并发和限流策略要根据运营商的审核和发送时间窗口单独调整。教案里放的是“起始配置”，不是“标准答案”，理解每个参数为什么这么设置，比抄参数本身重要得多。

5. 短信发送流程避坑指南：5个踩过才懂的真实问题

5.1 状态报告丢失：短信发出去了，但回执一直不来

现象是用户已经收到短信，业务系统却始终没有收到状态报告，订单状态一直停在“发送中”，用户重复点击获取验证码，系统再次发送，造成重复短信。

原因是状态报告是异步推送，依赖回调URL稳定。回调地址不可达、未做签名校验、网络闪断都可能导致报告丢失。另外部分通道对状态报告的回传率本身就不是100%，极端情况会漏报。

解决方法是两条腿走路：回调接收为主，主动查询兜底。教案里建议设计一个定时任务，每隔30到60分钟查询一次超时未回执的短信，以查询结果为准修正业务状态。同时回调URL必须支持重试推送，平台推失败后业务侧要返回明确状态让平台继续重推，不能静默丢弃。

5.2 短信内容被截断或出现乱码：长度问题比参数更隐蔽

现象是长短信发出后用户收到多条碎片短信，或者中文内容显示为乱码。

原因是短信按字符数计费，单条短信的容量取决于编码方式。纯英文和数字按GSM编码，160字符一条；中文按UCS2编码，70字符一条。超过70个字符的短信需要运营商做长短信拼接，拼接需要协议头，实际可用字符数会降到67个左右，不同运营商对长短信的拼接策略并不完全一致。

解决方法是教案里明确写入两条规则：一是内容超过67个中文字符时按长短信处理，并预先做好费用预估和展示预览；二是提交内容时明确声明编码格式，避免平台用默认编码解析中文导致乱码。业务系统侧还要防止把用户输入的换行符、emoji等特殊字符原样塞入短信内容，这些字符在部分通道里会被截断或转义异常。

5.3 重试风暴打垮业务系统：重发逻辑设计不当引发雪崩

现象是某次短信平台短暂故障，业务系统的重试任务在同一时间点集中重发积压的几十万条短信，短信平台限流，重试再次失败，又触发下一轮重试，系统负载飙升。

原因是重试任务没有做退避和抖动，大量失败任务在同一时间窗口内同时重试，形成对平台的集中冲击。这个问题在整点定时任务或故障恢复瞬间最容易出现。

解决方法是重试机制必须包含三项设计：重试次数上限、指数退避、随机抖动。指数退避让每次重试的间隔拉长，随机抖动避免重试任务在整点齐射。教案里建议用“30秒、5分钟、30分钟、2小时”四级重试间隔，并在每一级加上正负20%的随机偏移。重试任务还要做业务幂等，同一笔订单的重复提交不能生成多条短信。

5.4 签名和模板审核不过：内容合规是先决条件

现象是短信提交后返回“审核拒绝”或“模板不存在”，但业务系统代码看着没有问题，排查半天发现是签名和模板没过审。

原因是国内行业短信对签名和模板有明确要求。签名必须能代表企业身份，模板中的变量需要先报备，营销内容还要避开敏感词。很多团队把签名和模板当成“申请一次就不用管”的静态配置，实际上签名过期、模板变量调整、新增发送场景都需要重新审核。

解决方法是在教案里把签名和模板的申请流程单独成节，提醒学员在联调之前先确认签名和模板已过审，并留出1到3个工作日审核周期。生产环境还要建立签名和模板的监控，一旦收到审核拒绝状态，及时通知业务侧修改，而不是等用户投诉后再排查。

5.5 营销短信夜间被限流：送达率在特定时段大幅下降

现象是夜间发送的营销短信送达率明显低于白天，或者大批量提交的短信被运营商延迟到次日早上才下发。

原因是运营商对深夜时段（通常为晚上8点到次日早上8点）的营销类短信有频控和延时策略，尤其对未备案的营销内容管控更严格。验证码和通知类短信一般不受影响，但营销类通道会被限制下发速度。

解决方法是区分短信类型配置发送策略：验证码和通知走实时通道，营销短信避开深夜发送，最好在白天工作时段分批次提交，不要短时间集中冲击。教案里可以给一张分时段发送建议表，营销短信建议在上午10点到晚上6点之间分三到四批发出，每批间隔至少半小时，既能控制成本也能减少被限流概率。

6. 教案效果的验证方法：怎么判断学员真的懂了而不是听懂了

教案讲完不算结束，我习惯在培训后一周内做一个简单但有效的验证。

第一个方法是让学员手画链路图。不给任何参考资料，让每个人默画从业务系统到手机的四环节链路和一张异常分支图。如果学员只能画出“业务系统→短信平台→用户”这种三层模型，说明对运营商网关这一环的理解还是模糊的，需要回去重看教案里的流程图部分。

第二个方法是给一个故障场景让学员写排查方案。比如“某天上午10点，大量用户投诉收不到验证码，你按什么顺序排查”，要求学员按链路逐层排查并说明每个环节要看什么日志、查什么指标。这个验证能直接体现学员是否理解状态报告和主动查询的区别，也能看出学员是否掌握超时和重试参数的实际应用。

第三个方法是抽查真实状态码含义。不用考核冷门错误码，而是抽3到5个高频状态码，比如提交成功、短信平台拒绝、运营商失败、回执超时，让学员说明业务系统应该做什么。

这套验证做下来，学员的真实掌握情况就藏不住了。踩过坑的经验告诉我：培训时最危险的信号是学员频频点头，真到排查时却拿不出思路。与其让他们觉得“记住了”，不如逼着他们“画出链路、写出方案、讲清状态”。

教案这东西，做一次容易，做好一次难。每次讲完我都会把学员问到最多的几个问题追加到教案末尾，迭代两三轮之后，这份教案就不只是新人培训材料，而是团队排查短信问题的统一语言了。希望这份思路能帮你的教案少走些弯路。

本文还有配套的精品资源，点击获取