企业官网建设流程全解析

简介：这是一份短信发送流程学习教案，面向通信工程专业学生、移动网络运维人员及对信令交互机制感兴趣的读者。PPT围绕MO（移动发起）与MT（移动接收）两条主线，详细拆解漫游用户、省内互通、省外互通等典型场景中短信从发送方经由基站、MSC、LSTP、HSTP一路转发至SMSC，再完成鉴权、查询HLR并下发给目标用户的完整路径，清晰标注各网元的转发与应答关系，有助于理解跨省漫游时多层次信令交互及计费话单生成逻辑。资源包内含1个PPTX演示文档，共8页，约158KB，以流程图与步骤编号为主，适合培训宣讲、课堂讲解或自学梳理。已有67人学习了该资源。学习者可通过该教案快速掌握短信中心与信令网协同工作的机制，并为排查短信延迟、发送失败等实际网络问题建立基础认知。

1. 短信发送流程学习教案：一份教学 PPT 背后能挖出多少真东西

带过新人的读者应该都有同感：一份短信发送流程学习教案，最难的不是把接口文档念一遍，而是让新人真正搞懂“我点一下发送，这条短信到底经历了什么”。教案拆得好，新人半天就能上手调通第一个接口；教案只是抄官方文档，新人大概率在测试环境折腾一整天，最后用一句“我明明调通了但手机就是没响”收场。这篇内容从教案的实际授课逻辑出发，把短信发送流程拆成链路、代码、回执、避坑四个层面，适合两类人：一类是刚拿到短信平台接口文档、准备做第一次接入的开发者；另一类是要给团队做内部技术培训、正在憋教案 PPT 的技术负责人。短信发送这事看着小，真要讲清楚，背后的签名、模板、编码、回执每一样都能单独讲半小时。

2. 先看清短信发送链路：五个泳道和一条短信的完整旅程

2.1 三种接入方式：直连运营商、平台 API 和云厂商短信服务怎么选

教案第一页不用急着写接口，先把“短信送到手机上要经过谁”这件事画清楚。从业者常说的三种方式，差别不在发短信本身，而在你要背多少运维成本。

第一种是直连运营商，也就是直接对接移动、联通、电信的短信网关，走 SMPP、SGIP 这类协议。这种方式适合日发送量极大、有自己的通道资源和合规资质的团队，普通人基本不用考虑，运营商的接入门槛和协议复杂度足够劝退。第二种是短信平台 API，这是大多数中小团队在用的做法。平台帮你维护运营商通道，你只需要调一个 HTTP 接口。第三种是云厂商的短信服务，本质也是平台 API，但胜在控制台体验好、文档规范、有现成的统计报表，适合第一次接入短信的新团队。

教案里我一般建议并列放一张三行对比表，把接入成本、维护成本、发送单价、适用量级四列写清楚。选型的核心逻辑其实一句话：团队里没有专人懂 SMPP 协议，就不要碰直连，老老实实 API 接入。授课时用这个对比开场，比一上来扔接口文档好讲得多。

2.2 泳道图怎么画：业务系统、短信平台、运营商网关、手机端谁先谁后

短信发送流程里最容易让新人懵的，是“发送成功”和“手机收到”之间的那段真空地带。教案里画一张横向泳道图，四个泳道从上到下：业务系统、短信平台、运营商网关、手机终端。主链路的顺序是：业务系统组装手机号和内容，HTTP 提交给短信平台；平台做验签、鉴权、模板校验和频控检查，通过后把内容转成运营商要求的格式；运营商网关按号段路由到对应省份，再下发到手机；手机终端解析短信内容并展示。

这张图讲透之后，再补一条纵向的回执链路。手机收到短信后，终端会向运营商返回状态报告，运营商把报告回传给短信平台，平台再通过回调或查询接口把最终状态交给业务系统。教案的讲解顺序建议是先横着走主链路，再竖着看回执链路，让新人心里先有一条线，再往线上挂细节。

需要给新人点名的几个环节：短信平台里有一个反垃圾策略引擎，会按频控规则限制单号码的发送次数；运营商网关上还有内容过滤，所以平台审核通过的模板，到了运营商那边也可能被拦。画泳道图的时候，这两个拦截点必须画成检查框，不然新人会误以为模板过了审就万事大吉。

2.3 签名和模板：为什么 80% 的新人第一轮都被卡在审核这一关

教案讲到中间，一定要单独留一页给审核规则，因为实际踩坑的人太多了。签名就是短信开头的【XXX】那部分，个人开发者想用“【张三】”这种纯个人名义的签名，几乎不可能通过；企业签名需要提供营业执照，用品牌名还需要对应的商标或授权书。模板是短信正文的骨架，像“您的验证码为${code}，${time}分钟内有效”这样，把变量框出来，平台审核的是去掉变量之后的静态内容。

审核驳回的高频原因就三类：签名和资质不匹配，模板里带了营销敏感词，以及变量命名不规范。写教案时建议直接把驳回截图放上去，把驳回理由和修改方法一一对应列出来。新人在这一步最容易心态崩——明明自己觉得内容没问题，平台就是不给过。教案里写清楚审核是前置环节，不是发送时才校验，新人的困惑能消掉一大半。

3. 从教案到代码：三个参数、一个签名函数、半小时跑通首条短信

3.1 准备接入参数：appId、appSecret、模板编号一个都不能少

进入动手环节，先别写代码，让新人打开短信平台的控制台，创建应用并开通短信服务。绝大多数平台的接入参数是一致的：appId 是应用标识，appSecret 是密钥，签名编号和模板编号分别在签名审核和模板审核通过后生成。第一次接入时常见的低级错误是把 appSecret 直接写在代码里提交到 Git，教案里要专门提醒这一点。

参数准备好之后，先把下面这段 Python 脚本发给新人。这段代码只做一件事：生成请求签名。绝大多数短信平台的签名逻辑是对 appId、时间戳、appSecret 做 MD5 摘要，具体拼接顺序每个平台略有差异，但思路一样——把请求参数和密钥搅在一起，防止请求被篡改。

import hashlib import time app_id = "your_app_id" app_secret = "your_app_secret" # 取当前秒级时间戳作为请求参数的一部分 timestamp = str(int(time.time())) # 常见的签名拼接方式：appId + appSecret + timestamp # 部分平台要求按字典序对参数排序后再拼接，看平台文档 raw_string = app_id + app_secret + timestamp sign = hashlib.md5(raw_string.encode("utf-8")).hexdigest().upper() print(f"timestamp: {timestamp}") print(f"sign: {sign}")

这段代码里的 MD5 是明文摘要，做不到绝对安全，但它在这个场景下的作用是防重放，而不是防破解。timestamp 每次都变，签名也跟着变，平台收到请求后会按同样的算法重算一次签名，比对一致才放行。注意 .upper() 这一步，有的平台要求小写，有的要求大写，接口文档里没写清楚的话，先用一个简单的打印比对，或者直接问对面技术支持。

3.2 发送接口怎么调：把模板变量和安全意识一起教给新人

签名通了，发送接口就是一个普通的 POST 请求。短信平台的发送接口大同小异，核心字段就几个：手机号、模板编号、模板变量列表。手机号参数在多号码群发时一般用逗号分隔，但授课时只建议传单号码，避免触达频控。模板变量的传法有两种，一种是 JSON 字符串，一种是平台自定义的键值格式，以下代码按最常见的方式演示。

import requests url = "https://api.example-sms.com/send" headers = {"Content-Type": "application/json"} mobile = "13800000000" template_id = "SMS_2024001" # 模板内容：您的验证码为${code}，${min}分钟内有效 variables = { "code": "628493", "min": "5" } payload = { "appId": app_id, "timestamp": timestamp, "sign": sign, # 用上一节生成的签名 "mobile": mobile, "templateId": template_id, "variables": variables } resp = requests.post(url, json=payload, headers=headers, timeout=10) result = resp.json() # 多数平台的响应体里会有 code/message 两个字段 if result.get("code") == "0" or result.get("code") == 200: print(f"请求受理成功，消息ID: {result.get('messageId')}") else: print(f"请求失败: {result.get('message')}") # 常见失败：签名错误、模板未过审、手机号格式异常

这段代码有三个值得在教案里展开的点。第一，timeout 必须设，默认超时时间过长会导致发送线程堆积，高峰期能把业务服务拖死。第二，result 里的 messageId 一定要存下来，后面查回执、对账、用户投诉排查都靠它。第三，不要用异常代替业务判断——网络异常抛的是 requests 的异常，业务失败返回的是响应体里的错误码，两种要靠 code 区分。

3.3 教案配套测试用例：四步让新人自检而不是追着你问

代码跑通之后，教案里一定要附一张测试用例表，让新人照着自测。我常用的四步是：第一步用正常参数发一条，断言返回 code 为成功且 messageId 非空；第二步把 appSecret 改错，断言返回签名错误；第三步换一个未过审的模板编号，断言返回模板不存在；第四步把手机号改成 123，断言返回号码格式错误。表格里每行列四个字段：用例名称、操作步骤、预期结果、失败时看什么。这四步跑完，新人基本不会再拿着低级问题来找你。

4. 别把请求成功当成送达成功：状态回执是短信教案里分量最重的一页

4.1 回执状态怎么读：DELIVRD 才是真成功，其他状态码都有含义

教案讲到这，有一个反直觉的结论必须点出来：HTTP 请求返回成功，只代表短信平台受理了你的发送请求，不代表手机用户已经看到。真正决定送达与否的，是短信平台收到运营商回传的状态报告之后给你的那个最终状态。最常见的成功状态是 DELIVRD，意思是用户手机已成功接收。常见失败和中间状态里，发送中状态叫 SENDING，用户手机关机或不在服务区是 EXPIRED，号码空号或停机是 UNDELIV，被运营商拦截是 REJECTD。

这部分适合放一张状态码速查表，把英文全称、中文含义、出现场景、对应处理建议四列排开。特别是 SENDING 这个状态，很多新人一看“还没失败”就一直等，实际上 SENDING 超过一定时间没转 DELIVRD，基本就是运营商通道阻塞，这时候应该走人工介入或改走备用通道，而不是傻等。教案里要强调“结局状态只有 DELIVRD 一种，其余都要当成异常来看”。

4.2 回执获取的两种姿势：HTTP 回调推送和主动查询拉取怎么选

平台拿到运营商回执之后，业务系统要怎么拿到这个结果？常见做法是两种。第一种是回调推送，你在创建应用时配置一个回调地址，平台把回执数据 POST 过来；第二种是主动查询，你拿着 messageId 轮询平台的查询接口。回调推送时效最好，但要求你的服务有公网可达的接收端；主动查询实现简单，但轮询不能太频繁，不然会被平台限流。

下面是回调接收端的 Flask 示例，实际生产环境建议用 FastAPI 或者直接挂到已有的 Web 服务上：

from flask import Flask, request, jsonify app = Flask(__name__) # 回调地址: 由平台配置，例如 https://your-domain.com/sms/callback # 平台会用 POST 方式推送回执 JSON @app.route("/sms/callback", methods=["POST"]) def sms_callback(): data = request.get_json() # 不同平台字段名不一样，常见的有 messageId、status、statusDesc # 部分平台会对回调内容做签名，验签逻辑参考 3.1 的签名算法 message_id = data.get("messageId") status = data.get("status") # 例如 DELIVRD status_desc = data.get("statusDesc", "") # 建议先落库，再做业务处理，不要先发通知再存数据 # 这里打印日志是给教案演示用，生产环境换成真正的存储 print(f"messageId: {message_id}, status: {status}, desc: {status_desc}") if status == "DELIVRD": # 标记该短信为已送达，例如更新订单表中的短信状态字段 pass else: # 进入失败处理流程：重试、换通道或记录告警 pass # 注意：平台要求回调接口返回 HTTP 2xx 才算送达成功 # 如果你的服务处理逻辑抛异常，平台会按策略重推 return jsonify({"code": 0})

回调接口有两条铁律必须写进教案。第一，收到回调先落库再做业务逻辑，防止回调在业务处理中途崩掉导致数据丢失；第二，接口必须对外暴露且响应要快，平台有一套重推策略，你返回超时或 5xx，它会隔一段时间再推一次，你的接口就得有幂等处理，同一个 messageId 重复收到回调不能重复发奖励。教案里如果没有强调幂等，新人后期必然要在“回调重复”这件事上翻一次车。

4.3 回执数据里能看到什么：送达率、失败趋势和通道健康检查

回执不只是用来对账的，它还是判断短信通道质量的窗口。我一般会让团队每天拉一次回执统计数据，看三个指标：送达率、失败率、平均送达耗时。送达率低于 95% 就要查原因，是内容被拦截还是号段问题；失败率突然升高，大概率是通道侧出问题了，要准备切备用通道；平均送达耗时飙升，用户侧的验证码体验会明显变差，这种隐性故障靠发送接口的成功率是发现不了的。

这个环节在教案里可以顺带提一下机器人流程自动化的价值——回执统计这类每天固定时间拉数据、出报表、触发告警的动作，用 RPA 脚本或定时任务就能自动化，但 RPA 只能帮你把活跑起来，指标怎么解读还是得靠人。授课时把回执数据的一页报表截图放出来，让新人自己翻译每个状态码背后的用户场景，比讲十页理论都管用。

5. 短信发送流程避坑指南：五个让新人原地翻车的真实场景

5.1 测试号码一直收不到短信：模板没过审，还是号码没加白名单

现象：接口返回成功，messageId 也有，但测试手机就是收不到。原因多数出在平台侧的“测试模式”配置上。很多短信平台区分正式模式和测试模式，测试模式只对白名单内的手机号放行。新人往往配置了 appId 和 appSecret，漏了把测试号码加入白名单这一项。解决方式是先去控制台确认当前应用处于什么模式，把测试手机号加进白名单，然后重新发一条。如果白名单没问题，下一个同概率的嫌疑是模板状态还在审核中，发送接口对未过审模板的报错有时不显眼，新人容易看漏。

5.2 一条长文案被拆成三条计费：长短信拆分规则没搞懂

现象：发了一条约 200 字的通知，账单显示扣了 3 条费用。原因是短信有单条字数上限，纯中文字符的普通短信是 70 字一条。加了签名【某公司】之后，签名本身也占字符，实际可用字数会变成 65 字左右。超过上限后，平台会自动做长短信拆分，按 67 字一条切分计费。解决方式是把文案精简到一条之内，或者接受拆分并在教案里明确告诉业务方“长短信按拆分后的条数计费”。新人最容易在这里吃哑巴亏，因为发送接口返回的成功信息里看不到费用明细。

5.3 状态显示 DELIVRD 但用户说没看到：手机系统拦截与格式化符号

现象：回执已经是 DELIVRD，用户一口咬定没收到。原因排查要跨出短信链路，落到手机终端侧。常见情况是手机自带的安全软件把带链接、带营销语气、带特殊符号的短信静默拦截了。解决方式是先让用户检查拦截记录，确认被拦截后再考虑调整文案风格。教案里要把这个场景和通道故障分开，不要让新人误判为平台侧问题，最后自己去系统里翻半天下载日志，整个链路里最不值得花时间的就是终端黑匣子的部分。

5.4 营销内容被运营商拦截：模板过了平台的审，不代表过了运营商的关

现象：平台模板审核通过，发送接口也正常，但回执里出现拦截类状态码，或者送达率显著低于验证码类短信。原因是运营商网关侧有独立的内容过滤策略，平台审过了还会被运营商再审一道。解决方式是两个方向：一个是内容上远离明显营销信号，比如去掉“免费”“红包”“点击”这类触发词，别用变体字或火星文去钻空子，变体字只会让拦截概率更高；另一个是发送时间避开用户投诉高峰。这块没有公式可套，教案里建议直接给一份高频拦截词对照清单，让业务方写文案时自行避开。

5.5 回调地址一直收不到推送：公网访问不通，还是验签逻辑没写

现象：控制台里回调地址配了，代码也部署了，但接口始终收不到平台的回调。最常见原因是回调地址所在的服务没有对公网开放，平台推送请求直接超时；第二个常见原因是平台侧要求回调地址必须备案过，没备案的域名会推不进来；第三个原因是接口逻辑里有验签，验签不通过直接丢弃了请求。解决方式是先关掉验签看能不能收到裸推送，把链路跑通后再按签名算法把验签加回去。教案里要提醒新人，排错要按“通不通、验不验、存不存”三步走，不要一上来就怀疑平台丢了数据。

6. 把教案变成团队的活手册：频控验证、回归脚本和考核用例的进阶玩法

教案到这里，新人的主链路已经通了，但离“能独立值班”还差最后一步：学会验证自己的改动有没有破坏短信发送流程。我习惯带团队做的事是每次短信相关代码变动后，跑一遍五步回归验证。第一步，用测试号码发一条验证码模板，确认入库消息状态和回调状态都能对上；第二步，同一号码一分钟后连续发两条，确认触发频控拦截，返回错误而不是重复下发；第三步，发一条含敏感词的营销文案，确认被拦截并记录拦截理由；第四步，检查前置环境，把 appSecret 故意改错，确认签名失败；第五步，停掉回调接收服务，确认平台侧触发重推，服务恢复后能收到补推数据。这五步覆盖了链路、频控、内容、签名、回调五个最脆弱的位置，任何一步挂了都要在发布前拦住。

频控验证是个容易忽略的点。很多团队只顾功能通不通，忘了验证频控规则的边界。频控不是防你的正经业务，是防短信被薅成骚扰工具。教案里建议写清楚两个层级的频控：单号码一分钟内最多一条、单号码一天内最多十条，这两个阈值一旦越过，平台会直接拒绝发送。验证时不要用生产环境自己的手机号测频控，一个不小心就把自己的号码封了，后悔药可不是每次都有。

回归脚本是第二步进阶动作。用定时任务把回执统计和送达率日报跑起来，每天上班前看一眼。做这个不用追求大而全，一个脚本拉数据，一个脚本算指标，指标超过阈值自动在群里喊一声就行。这块和 RPA 是天然搭配，定时拉取、解析、汇总、告警的重复劳动交给工具，人只处理异常。我的习惯是每个季度把回执状态码里出现过的非 DELIVRD 值重新过一遍，看看有没有新的拦截理由冒出来，有的话补进教案的避坑页。

最后是给新人的考核环节。教案的收尾不应该是一个句号，而是一份检查清单：能独立完成新模板申请并对审核驳回给出修改方案，能在排除终端拦截的前提下判定一次发送投诉是平台问题还是内容问题，能看懂回执报表并说出送达率异常的排查路径。带团队这几年，我最大的教训是把短信流程想得太简单，直到一次验证码大面积延迟才真正开始重视回执监控。这份教案进阶到活手册之后，新人上手从三天缩到半天，生产事故从每月一次降到半年一次。希望帮到你。

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