简介《短信发送流程学习教案》是一份面向通信专业学生、网络运维或计费相关人员的专业资料以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 可复用的教案参数配置表拿来改一改就能用如果不想从零设计教案里的参数页可以直接用下面这张配置表作为底稿根据实际短信平台的能力做增删参数项推荐值配置位置备注调用接口超时3秒业务系统HTTP客户端超过后标记失败并计入重试等待状态报告超时30分钟业务系统定时任务超时后主动调用查询接口提交失败重试次数3次业务系统重试队列第3次失败后转人工告警重试间隔30秒/5分钟/30分钟业务系统重试队列指数退避避免集中冲击单通道TPS上限200短信平台通道配置超出后本地排队队列积压阈值1万条业务系统监控触发告警并扩容或降级状态报告推送地址公网回调URL短信平台配置必须支持HTTPS和签名校验签名与模板已过审签名/模板短信平台审核后台审核周期一般1到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个高频状态码比如提交成功、短信平台拒绝、运营商失败、回执超时让学员说明业务系统应该做什么。这套验证做下来学员的真实掌握情况就藏不住了。踩过坑的经验告诉我培训时最危险的信号是学员频频点头真到排查时却拿不出思路。与其让他们觉得“记住了”不如逼着他们“画出链路、写出方案、讲清状态”。教案这东西做一次容易做好一次难。每次讲完我都会把学员问到最多的几个问题追加到教案末尾迭代两三轮之后这份教案就不只是新人培训材料而是团队排查短信问题的统一语言了。希望这份思路能帮你的教案少走些弯路。本文还有配套的精品资源点击获取