简介在移动办公和多卡场景下短信分散在多个设备容易漏掉关键通知。借助消息路由机制可以将短信转化为可编程的推送事件。Android系统通过有序广播通知应用接收短信开发者可基于BroadcastReceiver捕获PDU数据并结合SubscriptionManager识别SIM卡槽构建灵活的规则引擎实现按发件人、内容、卡槽的精准匹配。短信转发工具的价值在于打破短信与具体设备的绑定将验证码、银行通知等关键消息统一投递到Webhook、Telegram或SMTP等目标通道。无论是自动化运维还是个人效率提升合理配置规则与通道能显著减轻漏看短信的焦虑。以SmsForwarder为例剖析监听机制、规则优先级、模板变量与保活策略帮助读者快速搭建属于自己的短信转发管道。1. 短信转发器不是把短信挪个地方那么简单手机卡一多短信就散工作号绑定的验证码收在备用机里快递通知落在双卡手机的第二槽人不在工位时漏掉一条银行提醒就得花半小时翻历史记录。SmsForwarder 这类短信转发器的定位是把 Android 手机的收件箱变成一个可编程的消息入口收到短信的瞬间按规则匹配 SIM 卡槽、发件人、关键词再把内容投递到 Webhook、Telegram Bot、钉钉/企业微信群机器人、SMTP 邮箱或 MQTT。它解决的不是存储问题而是路由问题——谁收到了消息以及如何按意图分发。常见做法是跑一个常驻 Android 应用监听系统广播在本地完成规则匹配后异步推送。背后依赖的是短信广播的时序、通知栏权限和后台存活策略。适合的人群也很明确多卡用户、跑自动化脚本的开发者、有服务器要接收手机端通知的运维。这篇文章会把监听机制、规则优先级、通道配置和调试手段串起来让你拿到手机就能配通而不是到处拼碎片教程。2. 消息从哪来SmsForwarder 的短信监听与卡槽识别机制2.1 系统广播时序为什么监听要在 onReceive 里抢时间Android 系统收到短信时会发出一条顺序广播android.provider.Telephony.SMS_RECEIVED。所有注册了该广播接收器的应用都会收到这次回调SmsForwarder 可以在应用列表中声明接收器并注册高优先级。关键点是这条广播是有序广播意味着每个接收器可以按优先级依次处理并且可以中止广播继续传递。短信转发器要做的是在第一时间读取pdus字段里的原始短信数据解析出短信内容、发件号码、接收时间然后触发规则匹配整个过程必须抢在系统短信应用写入收件箱之前完成否则某些 ROM 会延迟广播或导致重复处理。代码层面做监听的核心是一个继承BroadcastReceiver的类在onReceive里从 Intent 中解出短信数组。对外发短信也有对应广播SMS_SENT_ACTIVITY不过 SmsForwarder 一般不监听发送状态只关注接收链路。需要注意 Android 8.0 之后隐式广播限制并没有砍掉 SMS_RECEIVED因为它属于系统受保护广播应用仍能可靠注册。若在部分国产 ROM 上收不到广播通常是电源管理策略把进程杀掉了而不是广播本身的问题。2.2 SIM 卡槽信息如何变成 senderKey双卡双待手机上光知道收到一条短信还不够规则里要区分是卡 1 还是卡 2 收到的。Android 提供了SubscriptionManager通过getActiveSubscriptionInfoList()能拿到每个 SIM 的 subscription ID、ICCID、号码。短信广播的 Intent 里并没有直接暴露 subId但可以通过telephonyManager.getDefaultSmsSubscriptionId()或从短信数据里的SubscriptionManager.UNIQUE_KEY_SUBSCRIPTION_ID字段取到。SmsForwarder 把这种关联抽象成一个概念叫senderKey一个 senderKey 对应一张 SIM 卡。例如手机里插了两张卡Sim1 对应 senderKeysim1Sim2 对应 senderKeysim2。用户可以在配置里把这个 key 命名为工作号或生活号后续每条转发规则通过指定 senderKey 来决定只有某张卡收到的短信才走这条规则。这样实现的是转发器最核心的隔离能力卡 1 收到的验证码推到群 A卡 2 收到的快递通知推到群 B互不干扰。我在实际使用中会把卡槽别名做得更语义化bank、courier、home比sim1更可读也更便于在规则 JSON 里维护。2.3 匹配规则引擎的正则与多条件组合匹配不只靠发件人号码。SmsForwarder 的规则引擎支持多个条件组合发件人可用正则、短信内容可用正则、senderKey卡槽、时间窗口、关键词排除。判断逻辑通常是先做精匹配再做模糊匹配最后落到默认规则。正则表达式用的是 Java 的java.util.regex语法因此写规则时要注意\d、\w这类转义在 JSON 配置里需要写成双反斜杠。一个典型的多条件规则结构类似{ ruleName: 银行验证码, senderKey: bank, senderRegex: 955(88|33), contentRegex: 验证码[是为]\\s*([0-9]{4,8}), excludeKeywords: [广告, 退订], timeRange: {start: 08:00, end: 22:00}, targets: [webhook_work, tg_private] }匹配时先判断 senderKey 是否为空或匹配当前卡槽再对发件人号码做正则最后在内容上跑正则。三个条件全部命中才执行转发。excludeKeywords是排除逻辑只要内容包含其中任意词就跳过。这套设计解决的问题很实在验证码短信可能来自各种通道号但内容和发件人组合后几乎不会误报配合广告退订排除词能把营销短信挡在门外。3. 把消息送出去SmsForwarder 的转发通道配置与消息投递3.1 HTTP/Webhook 通道最通用的出口SmsForwarder 把转发行为统一建模为连到某个通道并发送一条消息。HTTP/Webhook 通道是最灵活的一种可以对接任意的后端接口、群机器人、Server 酱等。配置时只需要提供 URL、请求方法默认 POST、请求头、请求体模板。请求体通常会注入几个固定变量{title}代表标题{content}代表短信内容{sender}代表发件人{sim}代表卡槽名{date}代表接收时间。一个对接企业微信群机器人的配置片段curl -X POST https://qyapi.weixin.qq.com/cgi-bin/webhook/send?keyYOUR_KEY \ -H Content-Type: application/json \ -d { msgtype: text, text: { content: [短信转发] 来自 {sender}\n{content}\n时间: {date} } }这里可以注意到一个细节企业微信机器人要求请求体里msgtype为text而钉钉机器人要求msgtype为text且内容不能超过 2000 字。如果你同时接了多个平台的群机器人每个通道的模板要单独适配不能一个 JSON 模板到处套。SmsForwarder 的通道配置允许自定义 header 和 body所以这种平台差异就留在转发器配置层解决后端接口本身不用为短信做定制。接口返回的状态码不是唯一判断依据。有些 Webhook 服务在业务层失败时也会返回 200比如消息内容命中平台风控、关键词被拦截。所以判断投递成功不能只看 HTTP 状态SmsForwarder 支持配置一个成功标识字段在响应体里包含该字段才认为是真正成功。这个配置项看似不起眼实际用起来能省掉很多假成功的排查时间。3.2 Telegram Bot 通道与长连接差异Telegram Bot 通道走的是 HTTPS 长轮询。SmsForwarder 使用 Bot API 的sendMessage接口配置时填 Bot Token 和 Chat ID 即可。它的运行机制不是每次转发才发起连接而是 Bot 客户端在后台保持一个长轮询连接。这意味着你的手机必须能稳定访问 Telegram 的 API 域名——网络环境不适合时不建议作为主通道容易造成消息延迟或丢失。如果确实要用 Telegram 作为主通道建议的替代方案是短信转发器先把消息推到自己的服务器走 Webhook 通道再由服务器上的一个轻量脚本调用 Telegram API。这样转发器的出口网络要求就大大降低任何国内云服务器都能承担中间层角色。3.3 SMTP 通道把短信转成邮件的场景边界SMTP 通道适合低频但必须留存的短信。配置需要邮件服务商提供的 SMTP 地址、端口、账号和授权码不是登录密码。以 QQ 邮箱为例SMTP 主机为smtp.qq.com端口 465SSL授权码需要在邮箱设置里单独开启。SmsForwarder 收到短信后会把短信内容作为邮件正文、发件人号码作为发件人显示名通过 SMTP 协议投递到预设收件人。邮件通道和其他通道最大的差异是异步性极高短信到达后要经历转发器进程发起 SMTP 握手、邮件服务商入站队列、收件方服务器拉取、客户端同步等多个环节整体延迟通常在秒级到分钟级。所以邮件通道适合作为存档用途不适合作为告警用途——真正要紧的验证码如果 3 分钟后才到邮箱基本没有实用价值。建议把邮件通道放在规则链的次要位置与即时通道并行投递。通道类型典型延迟可靠性适合场景HTTP/Webhook毫秒级高取决于接收端群机器人、自建后端Telegram Bot秒级中个人消息、离线通知SMTP 邮件秒~分钟级高存档、非紧急备份MQTT毫秒级中IoT 场景消息汇聚4. 规则与人卡绑定SmsForwarder 的生产级参数设计4.1 验证码提取正则捕获组在模板里的用法验证码转发最常用的场景是收到短信后只把验证码数字发出去。SmsForwarder 的正则捕获组可以把匹配到的部分存成变量在转发模板里用{1}、{2}引用对应的分别是第一个和第二个捕获组。比如短信内容是【XX银行】验证码 583920您正在登录15 分钟内有效。规则配置{ contentRegex: 验证码\\s*([0-9]{6}), targetTemplate: 验证码: {1} (来自 {sender}) }匹配时([0-9]{6})捕获了583920模板里的{1}就被替换为这个值。这里有个容易踩的坑如果规则里存在多个正则条件捕获组的编号是每个正则各自独立的不会跨正则合并。做复杂提取时要么把一个正则写得足够完整要么在模板里只引用最近一次匹配的捕获组。我一般会把验证码正则单独拆成一条规则避免与其他模糊匹配条件抢捕获组编号。4.2 多卡分流的优先级策略双卡手机常见的路由需求是副卡只转发不分流主卡全量转发。这种需求不能只靠 senderKey 做等值匹配还需要规则优先级。SmsForwarder 的规则列表是按配置顺序从上到下匹配的第一条命中的规则生效后续规则不再执行。所以要把最精确的规则放在最前面验证码规则 银行通知规则 快递规则 默认全量规则。优先级设计上有一条经验senderKey 精确匹配优先于正则模糊匹配。比如卡 1 上的银行短信和卡 2 上的银行短信通常来自不同通道号但内容结构相似。配置两条规则senderKey 分别指定不同卡槽内容正则共用同一个模式这样既保证了转发内容一致性又能按卡槽分流。如果反过来配卡槽信息就丢了。4.3 转发模板中的兼容字段与定制字段模板变量是通道配置和规则之间的桥梁。SmsForwarder 内建字段表如下字段名含义适用场景{title}标题默认取发件人或规则名推送通知标题{content}短信完整内容正文展示{sender}发件人号码来源标记{sim}卡槽别名senderKey区分来源{date}接收时间时间留痕{1}~{n}正则捕获组提取验证码等{ruleName}命中的规则名调试与路由模板可以自由组合这些字段但要留意各通道的消息长度限制。钉钉自定义机器人限制 2000 字符、Telegram 限制 4096 字符而短信全文通常只有百来个字正常情况下不会触顶。风险出在{content}里包含换行符或特殊字符时部分通道要求 JSON 转义。SmsForwarder 在投递模板时一般会做一次 JSON 序列化但如果你用的是自定义 HTTP 通道且请求头是text/plain则要自己处理换行问题。4.4 守护进程与保活参数解决被杀进程后的转发中断短信转发器是 Android 应用逃不开进程存活问题。SmsForwarder 的保活策略包括前台服务、通知栏常驻、电池优化白名单申请。在 MIUI、ColorOS、HarmonyOS 上以下设置缺一不可在系统设置中搜索自启动允许 SmsForwarder 自启动。在电池优化里将 SmsForwarder 设为不限制。在最近任务界面将该应用锁住。开启应用内的前台服务或常驻通知选项。代码层面SmsForwarder 通过前台服务startForegroundService维持进程优先级。如果系统还是定期杀进程需要检查是否开启了纯净模式或睡眠待机等深度省电功能。保活不是完全可靠——双清系统、恢复出厂设置、更换 SIM 卡后都要重新检查这些白名单。5. 排除误报与链路自愈SmsForwarder 的排查技巧与容错策略5.1 日志分析定位丢消息关注时间线而非只看错误短信转发丢消息的排查第一步别去看错误日志要先看时间线。SmsForwarder 的日志里会记录事件的三个阶段收到广播、命中规则、投递完成。如果日志显示收到广播但没有命中规则说明规则条件不匹配如果显示命中规则但没有投递完成说明通道或网络问题如果连收到广播都没有那就是系统层面的广播被拦截或进程被杀。这个三段时间线可以快速把问题收敛到接收端、匹配端、投递端三块比逐行读异常堆栈有效得多。有一个高频误区把收不到转发等同于转发器坏了。实际上很多情况是短信本身被系统拦截进了骚扰拦截文件夹广播仍然发出但内容被系统预置的拦截规则清空或标记为垃圾短信SmsForwarder 收到的content为空或只有提示文本。此时需要到系统短信应用的拦截记录里确认原始短信是否存在如果存在把发件人加入白名单即可。5.2 通道健康检查与自动重试参数SmsForwarder 的投递失败会触发重试策略但重试参数需要按通道类型调。HTTP 通道一般重试 3 次间隔 5 秒、30 秒、5 分钟指数退避比较合理。SMTP 通道重试次数不宜太多因为邮件服务器对频繁连接有频率限制。Telegram Bot 通道的重试要特别小心如果 Chat ID 错误重试多少次都没用会一直 404。在部署初期先手动把一条测试消息推到该通道验证通过后再挂到规则上。健康检查的做法是为每个通道配置一个独立的测试规则发件人关键字用test内容用ping。收到测试短信后通过各通道的通知延迟来评估链路质量。如果超过 2 分钟未收到某个通道的推送先检查该通道的 API key 是否过期——Telegram Bot Token、企业微信 Webhook 的 key 都有失效的可能且失效前没有任何预兆。5.3 告警风暴抑制合并同类短讯与静默时段验证码类短信有个特点同一场景下会频繁收到同号段短信。比如一条登录验证码没来得及用3 分钟内又触发了一次。SmsForwarder 不做任何抑制的话后端会连续收到多条几乎一样的消息。可以在规则里设置同类短信合并策略同一发件人在指定时间窗口内的相同内容合并为一条消息仅在内容变化时重新推送。典型参数是窗口 60 秒内容完全一致才合并。这个配置在抢票、监控类场景下能显著降低通道压力。静默时段的坑在于很多人把静默时段配置后发现白天也收不到通知。排查时先看时间格式SmsForwarder 通常接受HH:mm24 小时制但部分版本使用 12 小时制。配置静默时段是转发器本地时间不是服务器时间手机改时区后时段会跟随变化。对跨时区使用的用户建议把静默规则拆到具体时间区间而不是写死某个时段。验证链路的方式可以在服务器上开一个临时 HTTP 服务用nc -l 8080监听请求然后发一条测试短信直接查看转入的 JSON 体。这样能一次性确认广播、规则、模板变量、通道四条链路都正常比逐个环节单独验证要快得多。date -d $timestamp还能核对消息延迟里的时间戳时区偏移确认是投递延迟还是系统时间偏差。本文还有配套的精品资源点击获取
删除缺失值)
