简介这份《短信发送流程学习教案》PPT面向通信工程、网络运维方向的初学者与IT从业者系统梳理短信在移动网络中的端到端传递机制帮助读者理解各网元交互逻辑、排查短信收发异常。资源共1个pptx文件压缩包约158KB以图文分页形式呈现内容按流程类型逐页展开便于课堂讲解或自学对照。教案覆盖漫游用户MO、省内互通短信MO、省内用户MT、漫游用户MT、省外用户MT以及本地与异地互通短信MT等典型场景逐条标注BSC、MSC、LSTP、HSTP、SMSC、HLR、ISMG等节点的转发与应答步骤并涉及号段鉴权、计费话单生成等关键环节。目前已有67人学习适合需要快速建立短信信令流程整体认知、对照实际网络排障或准备相关课程考核的读者参考。1. 从一份短信发送流程学习教案.pptx说起短信到底是怎么发出去的很多人第一次接触短信发送流程学习教案.pptx是在新员工培训或者系统交接的场景里。打开这份教案看到的是几张流程图和一堆名词短信网关、短信中心、SP、通道、签名、模板、状态报告。但真正落到代码里问题就来了——为什么我调了接口返回成功用户却没收到为什么验证码延迟三分钟才到为什么同样的内容有的号码能发有的号码直接被拦截这份教案要解决的核心问题就是把「短信从业务系统到用户手机」这条链路拆开让开发和运维能定位到具体是哪一环出了问题。它适合三类人一是刚接手短信模块的后端开发二是需要排查短信到达率的运维三是做营销系统、需要控制发送成本和合规风险的业务方。短信不是「调个接口就完事」的东西它背后有运营商网关、有通道优先级、有模板报备、有频控和拦截策略。这篇笔记就顺着这份教案的思路把短信发送流程从原理到落地讲清楚重点放在「怎么配、怎么调、怎么排错」上。2. 短信发送链路的四层结构从业务系统到手机收件箱2.1 为什么短信不是「点对点直连」而是四层转发很多人以为短信是手机和手机之间直接通信实际上短信走的是存储转发机制。业务系统把消息提交给短信网关网关再路由到对应运营商的短信中心短信中心最终投递到用户手机。这中间任何一层出问题消息都可能丢失或延迟。具体来说短信发送链路分为四层第一层是业务系统也就是你自己的应用。它负责生成短信内容、选择模板、调用短信服务商的 API。这一层最容易出的问题是参数拼错、模板 ID 传错、手机号格式不对。第二层是短信网关通常由短信服务商提供。网关负责鉴权、计费、限流、路由选择。它会根据手机号归属地、通道负载、优先级策略决定这条短信走哪条通道。这一层的黑匣子属性最强因为你看不到内部路由逻辑只能通过状态报告反推。第三层是运营商短信中心也就是 SMSC。它负责最终的投递和状态回执。如果用户手机关机、不在服务区、短信收件箱满消息会在这里排队或丢弃。第四层是用户终端。手机收到短信后会返回一个确认信号这个信号再逐层回传最终变成你看到的「发送成功」状态报告。理解这四层结构的意义在于当用户说「没收到短信」时你要能判断问题出在哪一层。是业务系统根本没发出去还是网关路由错了还是运营商那边排队了还是用户手机拦截了每一层的排查手段完全不同。2.2 用最小请求跑通一次短信发送接口参数与返回码不管用哪家短信服务商发送接口的核心参数都差不多。下面是一个典型的 HTTP 发送请求示例用 Python 的 requests 库演示import requests import json import time import hashlib # 短信服务商提供的接入信息 API_URL https://sms-provider.example.com/v1/send ACCESS_KEY your_access_key SECRET_KEY your_secret_key def send_sms(phone, template_id, template_params): phone: 手机号带国家码如 8613800138000 template_id: 模板 ID需提前报备 template_params: 模板变量如 {code: 123456, minutes: 5} timestamp str(int(time.time())) # 签名串通常由 access_key timestamp secret_key 拼接后哈希 sign_str ACCESS_KEY timestamp SECRET_KEY sign hashlib.md5(sign_str.encode()).hexdigest() payload { access_key: ACCESS_KEY, timestamp: timestamp, sign: sign, phone: phone, template_id: template_id, params: json.dumps(template_params, ensure_asciiFalse), sign_name: 你的签名 # 需提前报备的短信签名 } resp requests.post(API_URL, datapayload, timeout5) result resp.json() # 常见返回码0 成功1001 签名错误1002 模板不存在1003 余额不足 if result.get(code) 0: return result.get(message_id) # 用于后续查状态报告 else: raise Exception(f发送失败: {result.get(code)} - {result.get(msg)}) # 调用示例 try: msg_id send_sms(8613800138000, SMS_123456, {code: 8888, minutes: 5}) print(f提交成功消息 ID: {msg_id}) except Exception as e: print(f提交失败: {e})这段代码的关键点有三个。第一签名生成方式各家不同有的是 MD5有的是 HMAC-SHA256一定要对照服务商文档签名错了会直接返回鉴权失败。第二手机号格式要统一国内号码一般要加 86 前缀去掉 号和空格否则网关可能路由到错误的国家通道。第三template_id 和 sign_name 必须提前报备并通过审核临时拼内容发送大概率被拦截。返回码是排查的第一手信息。0 表示提交成功但不代表用户已收到。1001 到 1003 这类错误是业务层能直接修正的比如换签名、换模板、充值。如果返回的是 2001 这类「通道拥堵」或「运营商拦截」那就不是改代码能解决的需要联系服务商换通道。2.3 状态报告怎么拿回调与轮询的取舍提交成功只是第一步真正要确认用户收到得看状态报告。状态报告有两种获取方式回调推送和主动轮询。回调推送是主流做法。你在短信服务商后台配置一个回调 URL当短信投递到用户手机后服务商会向这个 URL 推送状态报告。下面是一个 Flask 接收回调的示例from flask import Flask, request, jsonify app Flask(__name__) app.route(/sms/callback, methods[POST]) def sms_callback(): data request.json # 回调参数通常包含message_id, phone, status, receive_time, fee message_id data.get(message_id) phone data.get(phone) status data.get(status) # DELIVRD 成功UNDELIV 失败EXPIRED 过期 receive_time data.get(receive_time) if status DELIVRD: # 更新业务库标记该手机号已收到 print(f{phone} 已收到消息 ID: {message_id}) elif status UNDELIV: # 投递失败可能是空号、停机、拦截 print(f{phone} 投递失败原因: {data.get(reason)}) elif status EXPIRED: # 超过有效期仍未投递通常是手机关机太久 print(f{phone} 短信过期未送达) # 必须返回服务商约定的响应否则会重复推送 return jsonify({code: 0, msg: success}) if __name__ __main__: app.run(port8080)回调方式实时性好但要注意三点一是回调 URL 必须公网可达且响应要快超过 5 秒可能被判定失败并重推二是要做幂等处理同一条消息可能推送多次三是要校验回调来源 IP 或签名防止伪造回调。轮询方式适合回调不可用的场景比如内网环境。你定时调用服务商的查询接口用 message_id 批量查状态。轮询的缺点是延迟高、有频率限制一般作为兜底方案。提示状态报告里的 DELIVRD 只代表运营商侧投递成功不代表用户一定看到了短信。如果用户手机装了拦截软件短信可能被归到垃圾箱状态报告仍然是成功。3. 模板、签名与通道配置短信能不能发出去的三道门槛3.1 模板报备的硬性规则与变量设计短信模板不是随便写的。国内运营商对短信内容有严格审核模板必须提前报备审核通过后才能使用。模板报备的核心规则有几条第一模板内容必须与业务场景匹配。验证码模板只能发验证码营销模板只能发营销内容混用会被驳回。第二模板变量要用占位符表示比如「您的验证码是 ${code}${minutes} 分钟内有效」不能把变量写死在内容里。第三模板中不能包含敏感词、竞品名称、诱导分享链接。第四营销类模板必须包含退订方式比如「回 T 退订」。变量设计有个容易翻车的地方变量长度和类型要提前确认。有的服务商要求变量只能是数字或字母不能包含中文和特殊符号。如果你传的变量里有换行符或 emoji接口可能直接报参数错误。我一般会在代码里加一层变量清洗import re def clean_template_param(value): 清洗模板变量去掉换行、emoji、特殊符号 只保留中文、英文、数字和基本标点 if not isinstance(value, str): value str(value) # 去掉换行和制表符 value value.replace(\n, ).replace(\r, ).replace(\t, ) # 去掉 emoji 和其他非基本字符 value re.sub(r[^\u4e00-\u9fa5a-zA-Z0-9\s.,:;!?()【】], , value) # 截断过长变量一般不超过 20 个字符 if len(value) 20: value value[:20] return value.strip()这个清洗函数看起来简单但能避免很多「参数不合法」的报错。特别是验证码场景如果变量里混入了空格或不可见字符用户收到的验证码可能带空格导致校验失败。3.2 签名报备与通道选择为什么同样的内容有的号码收不到短信签名是附加在短信内容前面的标识比如【某某科技】。签名必须报备且要与你的业务主体一致。签名报备的常见问题有三个一是签名与营业执照名称不一致需要提供授权函二是签名涉及知名品牌需要提供品牌授权三是签名太长一般限制在 3 到 8 个字。通道选择是更隐蔽的问题。短信服务商通常有多个通道不同通道的覆盖范围、到达率、价格、发送速度都不同。比如通道类型适用场景到达率延迟价格验证码通道验证码、登录确认高低高通知通道订单通知、物流提醒中高中中营销通道促销、活动通知中高低国际通道海外号码视地区高很高验证码通道优先级最高但价格也最贵。营销通道便宜但容易被拦截且发送时间受限一般只能在 8:00 到 21:00 之间发送。通道选择的策略是验证码和重要通知走专用高优先级通道营销类走普通通道。如果预算允许可以配置通道备份当主通道拥堵或失败率上升时自动切换到备用通道。这个切换逻辑一般在短信服务商侧配置你也可以在自己的代码里做简单判断如果某通道连续 N 条返回「通道拥堵」就临时切换到备用通道。3.3 频控与黑名单避免被运营商限流的配置要点频控是短信发送里最容易踩坑的地方。运营商和短信服务商都有频控策略触发后轻则延迟发送重则直接封停通道。频控分几个维度单手机号频控、单 IP 频控、单账号频控、内容相似度频控。单手机号频控最常见比如同一号码 1 分钟内最多发 1 条1 小时内最多发 5 条24 小时内最多发 10 条。超过阈值后续短信会被丢弃或延迟。下面是一个简单的频控实现用 Redis 做计数器import redis import time r redis.Redis(hostlocalhost, port6379, db0) def check_frequency(phone, scenedefault): 检查手机号发送频率 scene: 场景标识不同场景独立计数 返回 True 表示允许发送False 表示被频控 now int(time.time()) # 1 分钟窗口 minute_key fsms:freq:{scene}:{phone}:minute # 1 小时窗口 hour_key fsms:freq:{scene}:{phone}:hour # 24 小时窗口 day_key fsms:freq:{scene}:{phone}:day # 使用 Redis 管道批量操作 pipe r.pipeline() pipe.incr(minute_key) pipe.expire(minute_key, 60) pipe.incr(hour_key) pipe.expire(hour_key, 3600) pipe.incr(day_key) pipe.expire(day_key, 86400) results pipe.execute() minute_count results[0] hour_count results[2] day_count results[4] # 阈值可根据业务调整 if minute_count 1: return False, 1 分钟内发送过于频繁 if hour_count 5: return False, 1 小时内发送次数超限 if day_count 10: return False, 24 小时内发送次数超限 return True, 允许发送这个实现用 Redis 的过期时间做滑动窗口简单有效。注意阈值不要设得太死比如验证码场景用户可能连续请求多次如果 1 分钟只允许 1 条用户体验会很差。我一般会把验证码场景的阈值放宽到 1 分钟 3 条但同一验证码内容重复发送要拦截。黑名单是另一个必须做的配置。用户回复「T」退订后必须把该号码加入黑名单后续营销短信不能再发。黑名单要持久化存储且要在发送前检查。有些服务商提供黑名单托管服务你只需要同步退订号码服务商侧会自动拦截。4. 短信发送避坑指南五条血泪经验4.1 现象接口返回成功用户没收到原因状态报告被忽略解决建立状态报告监控这是最常见的翻车场景。开发同学调完接口看到返回 code0就认为发送成功了。实际上 code0 只代表提交成功短信可能还在网关排队或者已经被运营商拦截。解决方法是建立状态报告监控。把回调收到的状态报告写入数据库按小时统计 DELIVRD、UNDELIV、EXPIRED 的比例。如果 UNDELIV 比例突然上升说明通道出了问题需要立即联系服务商。如果 EXPIRED 比例高说明用户手机关机或不在服务区可以考虑换时间段重发。监控指标建议包括提交成功率、投递成功率、平均延迟、各通道失败率。这些指标能帮你在用户投诉之前发现问题。4.2 现象验证码延迟几分钟才到原因通道拥堵或频控触发解决切换高优先级通道并调整频控阈值验证码延迟是用户投诉的重灾区。延迟的原因通常有两个一是通道拥堵短信在网关排队二是频控触发短信被延迟发送。排查方法是看状态报告的时间戳。如果提交时间和投递时间相差超过 30 秒基本可以判定是通道拥堵。这时候需要联系服务商把验证码场景切换到高优先级通道。如果状态报告显示「频控拦截」那就需要调整频控阈值或者引导用户稍后再试。我一般会在验证码发送接口里加一个超时判断如果 10 秒内没收到状态报告就自动切换备用通道重发一次。但要注意重发可能导致用户收到两条验证码所以重发前要检查是否已经有一条在途。4.3 现象营销短信被大量拦截原因内容含敏感词或发送时间不当解决内容预审加时间窗口控制营销短信的拦截率远高于验证码。常见原因有三个一是内容含敏感词比如「免费」「中奖」「点击领取」二是发送时间太早或太晚比如凌晨发送三是发送频率太高被用户投诉。解决方法是做内容预审。在发送前用敏感词库过滤一遍内容命中敏感词就拒绝发送或替换。敏感词库可以从服务商那里获取也可以自己维护。发送时间要控制在 8:00 到 21:00 之间且同一用户一天最多发一条营销短信。另外营销短信必须包含退订方式且退订要真实有效。用户回复 T 后必须在 24 小时内生效否则会被运营商处罚。4.4 现象国际短信发送失败原因号码格式或通道不支持解决按国家码分流并确认通道覆盖国际短信的坑比国内多。首先是号码格式不同国家的手机号长度和前缀不同不能统一按国内规则处理。其次是通道覆盖不是所有服务商都支持所有国家有些小国家需要专门的通道。解决方法是按国家码分流。在发送前先解析手机号的国家码然后路由到对应的通道。下面是一个简单的国家码分流逻辑def route_by_country(phone): 根据手机号国家码选择通道 phone: 带国家码的手机号如 8613800138000 # 常见国家码前缀 country_routes { 86: cn_channel, # 中国 1: us_channel, # 美国、加拿大 81: jp_channel, # 日本 82: kr_channel, # 韩国 65: sg_channel, # 新加坡 44: uk_channel, # 英国 } for prefix, channel in country_routes.items(): if phone.startswith(prefix): return channel # 未匹配的国家码走默认国际通道 return default_intl_channel这个逻辑需要定期更新因为国家码和通道的对应关系会变化。另外国际短信的价格差异很大发送前要确认余额充足否则会直接失败。4.5 现象回调接口被重复调用原因未做幂等或响应超时解决加唯一索引和快速响应回调接口被重复调用是常见问题。原因有两个一是你的接口响应太慢服务商认为失败于是重推二是服务商侧的重试机制同一条状态报告可能推送多次。解决方法是在数据库层加唯一索引。用 message_id status 作为唯一键重复插入时直接忽略。同时回调接口要快速响应不要在回调里做耗时操作比如发邮件、调外部接口。正确的做法是回调接口只负责把数据写入消息队列后续处理异步进行。# 数据库唯一索引示例 # CREATE TABLE sms_status ( # id BIGINT AUTO_INCREMENT PRIMARY KEY, # message_id VARCHAR(64) NOT NULL, # phone VARCHAR(20) NOT NULL, # status VARCHAR(20) NOT NULL, # receive_time DATETIME, # UNIQUE KEY uk_message_status (message_id, status) # );加上唯一索引后重复推送的数据会被数据库自动拒绝你只需要捕获异常并返回成功即可。5. 短信发送流程的进阶验证用日志和压测确认链路可靠性5.1 用结构化日志追踪每一条短信的完整生命周期要验证短信发送流程是否可靠光看接口返回码不够需要把每一条短信的生命周期都记录下来。我一般会在四个关键节点打日志提交请求、收到提交响应、收到状态报告、状态报告处理完成。日志用 JSON 格式方便后续检索和分析。import logging import json from datetime import datetime logger logging.getLogger(sms_trace) def log_sms_event(message_id, phone, event, detailNone): 记录短信生命周期事件 event: submit / submit_resp / callback / callback_done log_entry { timestamp: datetime.now().isoformat(), message_id: message_id, phone: phone, event: event, detail: detail or {} } logger.info(json.dumps(log_entry, ensure_asciiFalse)) # 在发送函数中调用 # log_sms_event(msg_id, phone, submit, {template_id: template_id}) # log_sms_event(msg_id, phone, submit_resp, {code: 0}) # 在回调中调用 # log_sms_event(message_id, phone, callback, {status: status}) # log_sms_event(message_id, phone, callback_done, {saved: True})有了这些日志你可以用 message_id 串起一条短信的完整链路。如果用户投诉没收到你可以快速查到提交时间是什么、提交响应是什么、有没有收到状态报告、状态报告是什么。这比凭记忆猜测靠谱得多。日志要保留足够长的时间一般建议至少 30 天。如果日志量太大可以按天分表或存到对象存储里。检索时用 message_id 或手机号作为关键词能快速定位。5.2 压测短信接口QPS 上限和失败率拐点怎么测短信接口的压测和普通接口不同因为短信服务商侧有频控和限流。压测的目的是找到两个关键值QPS 上限和失败率拐点。QPS 上限是指你的账号最多能承受多少条每秒的提交请求。超过这个值服务商会返回「限流」错误。失败率拐点是指当 QPS 上升到某个值时失败率开始明显上升。这个拐点通常低于 QPS 上限因为通道处理能力有限。压测方法是用阶梯式加压。从 10 QPS 开始每 30 秒增加 10 QPS观察失败率变化。当失败率超过 1% 时记录当前的 QPS这就是你的安全上限。压测时要用测试手机号不要用真实用户号码避免骚扰。压测脚本可以用 Locust 或 JMeter 写。下面是一个简单的 Python 压测示例import threading import time import requests def send_one(phone, template_id, results, index): 发送一条短信并记录结果 try: resp requests.post(API_URL, data{ phone: phone, template_id: template_id, params: {code: 1234} }, timeout5) result resp.json() results[index] result.get(code) except Exception as e: results[index] str(e) def pressure_test(qps, duration_sec, phone, template_id): qps: 每秒请求数 duration_sec: 持续秒数 total qps * duration_sec results [None] * total threads [] interval 1.0 / qps for i in range(total): t threading.Thread(targetsend_one, args(phone, template_id, results, i)) threads.append(t) t.start() time.sleep(interval) for t in threads: t.join() success sum(1 for r in results if r 0) print(f总请求: {total}, 成功: {success}, 失败: {total - success}, 失败率: {(total - success) / total * 100:.2f}%) # 测试 50 QPS持续 10 秒 # pressure_test(50, 10, 8613800138000, SMS_123456)压测时要注意不要用同一个手机号反复发会被频控拦截。可以准备一批测试号码轮换使用。另外压测最好在业务低峰期进行避免影响真实用户。5.3 一个具体技巧用状态报告反推通道质量状态报告不仅能告诉你短信有没有送到还能反推通道质量。我习惯每周拉一次状态报告数据按通道维度统计投递成功率和平均延迟。如果某个通道的成功率连续下降或者延迟明显上升就说明这个通道在劣化需要提前切换。具体做法是在状态报告表里加一个 channel 字段记录这条短信走的是哪个通道。然后写一个定时任务每天统计各通道的 DELIVRD 比例和平均投递时间。下面是一个 SQL 示例-- 按通道统计昨日投递情况 SELECT channel, COUNT(*) AS total, SUM(CASE WHEN status DELIVRD THEN 1 ELSE 0 END) AS delivered, ROUND(SUM(CASE WHEN status DELIVRD THEN 1 ELSE 0 END) / COUNT(*) * 100, 2) AS deliver_rate, ROUND(AVG(TIMESTAMPDIFF(SECOND, submit_time, receive_time)), 2) AS avg_delay_sec FROM sms_status WHERE submit_time DATE_SUB(CURDATE(), INTERVAL 1 DAY) AND submit_time CURDATE() GROUP BY channel ORDER BY deliver_rate ASC;这个查询能一眼看出哪个通道最差。如果某个通道的 deliver_rate 低于 90%或者 avg_delay_sec 超过 60 秒我就会联系服务商换通道。这个习惯帮我避免了好几次大规模投诉——通道劣化是渐进的等用户投诉再处理就晚了。说到底短信发送流程的可靠性不取决于你代码写得多漂亮而取决于你有没有把状态报告当回事、有没有持续监控通道质量、有没有在出问题之前就动手。我自己的习惯是每天早上花五分钟看一眼昨天的投递报表这个动作坚持了三年比任何事后补救都管用。希望帮到你。本文还有配套的精品资源点击获取