--- title: "推送通知与短信：区别及各自的适用场景" description: "推送通知与短信对比：触达范围、授权、计费模式、送达、富媒体内容和验证码可靠性，以及如何把两者结合并用短信作为回退。" canonical: "https://omnichannels.ai/zh/blog/push-notifications-vs-sms/" language: "zh" updated: "2026-11-05" publisher: "BroadNet Technologies" brand: "OmniChannels.ai" category: "omnichannel" primaryQuery: "push notification vs sms" keywords: ["推送通知和短信的区别", "短信还是推送通知", "验证码用推送还是短信", "推送失败回退短信", "App 通知与短信", "推送通知权限", "什么时候用短信代替推送"] published: "2026-11-05" author: "OmniChannels.ai Editorial Team" reviewer: "BroadNet Messaging Solutions Team" readingMinutes: 9 answer: "推送通知是通过 Apple 和 Google 发给已安装您的应用并允许通知的用户的自由格式提醒；短信则无需应用，可发到任何手机号码。推送适合低成本、富媒体的应用内互动，短信适合广泛触达和验证码等关键消息。两者可以结合：先发推送，时效性强的推送未读时再用短信回退。" takeaways: ["推送需要已安装的应用，并且在当前的 Android 和 iOS 版本上还需要用户授权；短信只需要手机号码，因此能触达推送无法到达的人。", "推送属于尽力而为的服务：Google 的 Firebase Cloud Messaging 文档说明不保证送达，消息 ID 仅表示 FCM 已接受该消息。", "推送适合互动和富媒体内容，如图片、深度链接和操作按钮；短信适合验证码、提醒，以及任何必须到达所有手机的内容。", "最好的设计是两者并用：先向应用用户发推送，关键消息在设定时间内未被打开时，用短信回退。", "显示推送的权限只是技术设置，不是法律意义上的同意记录。营销同意规则对两个渠道仍然适用，请保留自己的 opt-in 证据。"] faq: - q: "推送通知和短信有什么区别？" a: "推送通知通过 Apple 或 Google 的推送服务送达已安装的应用，只有用户允许通知时才会显示。短信通过移动网络发到手机号码，不需要应用或网络连接。推送更便宜、内容更丰富；短信触达更广，更适合关键消息。" - q: "验证码用推送还是短信更好？" a: "短信是更可靠的验证码默认选择，因为它能到达任何手机，不依赖应用是否已安装、已登录、已允许通知或已联网。推送可以更快地把验证码送给已登录的应用用户。许多团队先对应用用户发推送，验证码未被使用时再回退到短信。" - q: "用户必须同意才能接收推送通知吗？" a: "在 Android 13 及更高版本上，应用请求 POST_NOTIFICATIONS 权限并获得用户授权之前，通知默认是关闭的。Apple 的平台同样会向用户请求权限。这是一项设备设置；是否还需要有记录的营销同意取决于当地法律，请咨询律师。" - q: "推送通知比短信便宜吗？" a: "通常是的。推送由 Apple 和 Google 的服务承载，而不是移动运营商，所以一般没有按条计算的运营商费用，而短信按条（分段）和目的地计费。推送的真实成本包括应用、推送平台，以及让用户允许通知所需的投入。" - q: "可以同时发送推送和短信吗？" a: "可以，这也是常见做法。先发推送，如果关键消息在设定时间内没有被打开或处理，再发短信。如果用户已在应用中操作，则取消短信。不要在两个渠道同时发送相同的促销；这会被视为垃圾信息并推高退订率。" - q: "手机离线时，推送通知会怎样？" a: "使用 Firebase Cloud Messaging 时，消息会被存储，并在设备重新联网后送达，直到存活时间（time-to-live）到期；如果不设置，最多保留四周。存活时间为零的消息如果无法立即送达就会被丢弃。时效性强的内容请设置较短的存活时间。" sources: - title: "Notification runtime permission, Android Developers" url: "https://developer.android.com/develop/ui/views/notifications/notification-permission" - title: "Setting the lifespan of a message, Firebase Cloud Messaging" url: "https://firebase.google.com/docs/cloud-messaging/customize-messages/setting-message-lifespan" - title: "Asking permission to use notifications, Apple Developer Documentation" url: "https://developer.apple.com/documentation/usernotifications/asking-permission-to-use-notifications" - title: "3GPP TS 23.038: Alphabets and language-specific information" url: "https://www.3gpp.org/dynareport/23038.htm" --- # 推送通知与短信：区别及各自的适用场景 Canonical: https://omnichannels.ai/zh/blog/push-notifications-vs-sms/ Language: zh Publisher: OmniChannels.ai by BroadNet Technologies 本指南面向正在决定如何在手机上触达客户的产品经理、增长团队和开发者：是用应用的推送通知，用短信，还是两者并用。内容定义了这两个渠道，在触达范围、授权、计费模式、送达、内容和安全方面对它们进行比较，并说明如何结合使用，避免漏掉关键消息。 ## 什么是推送通知，什么是短信？ 推送通知是服务器通过操作系统的推送服务发送到用户设备上的消息，例如 Android 上的 Firebase Cloud Messaging（FCM）或 iOS 上的 Apple Push Notification service。即使应用已关闭，它也会显示。机制详见我们的[推送通知术语表词条](/zh/glossary/push-notification/)。 短信（SMS，Short Message Service）是通过移动网络发到手机号码的文字消息。它不需要应用、流量套餐，也不需要您这边有任何账号。[A2P 短信](/zh/glossary/a2p-sms/)是由应用发给个人的短信，例如验证码或配送提醒。 两者在结构上的区别在于标识符。推送针对的是绑定在您已安装应用上的设备令牌（token）。短信针对的是手机号码。其他差异都源自这一点。 ## 推送通知和短信如何比较？ 推送在成本和丰富程度上占优；短信在触达范围和确定性上占优。下表总结了二者的差异，不依赖各厂商的统计数据，因为这些数据差别很大且无法相互比较。 | 因素 | 推送通知 | 短信 | |---|---|---| | 谁能收到 | 已安装您的应用并允许通知的用户 | 网络上的任何手机号码 | | 是否需要应用 | 需要 | 不需要 | | 是否需要联网 | 需要（流量或 Wi-Fi） | 不需要，只需网络信号 | | 授权 | 当前 Android 和 iOS 的运行时权限 | 设备上无需授权；各国有用户同意规则 | | 计费模式 | 每条消息没有运营商费用；您为应用和平台付费 | 按条（分段）和目的地计费 | | 内容 | 标题、文本、图片、深度链接、操作按钮 | 纯文本和链接；GSM-7 为 160 个字符，Unicode 为 70 个 | | 送达 | 通过 Apple/Google 尽力而为，无保证 | 每条消息都有运营商送达报告 | | 发送者身份 | 您的应用名称和图标 | 字母数字发送方 ID 或号码，许多国家需注册 | | 回复 | 点击进入应用 | 可进行双向短信 | | 典型作用 | 互动、提醒、应用内更新 | 验证码、关键提醒、触达应用用户之外的人 | 富媒体功能很重要。我们的[推送 API](/developers/push/)支持图片、深度链接、操作按钮、模板、折叠键（collapse key）和定时发送。短信无法与之相比，但对一年前就删除了您应用的客户仍然有效。 ## 用户必须允许推送通知吗？ 在当前的手机上，是的。在 Android 13（API 级别 33）及更高版本上，新安装应用的通知默认是关闭的；应用必须请求 `POST_NOTIFICATIONS` 运行时权限，用户必须授权（Android Developers）。Apple 的平台同样会请求用户授权通知。如果用户拒绝，或之后在设置中关闭通知，您的推送就看不到了。 这是最大的触达限制。推送的受众是已安装应用、允许通知且尚未关闭通知的那部分客户。对拥有热门应用的银行来说，这可能是大部分活跃客户；对有大量纯网页买家的零售商来说，可能只是少数。请衡量自己的 opt-in 比例，而不是依赖行业基准。 由此得出两点实用建议： - **在合适的场景中请求授权。** Android 的指南建议在用户做出能让价值变得清晰的操作时（例如下单）请求权限，而不是在首次启动时。 - **保留自己的同意记录。** 设备权限并不能证明营销同意。当地法律可能要求任何渠道的营销都有记录在案的同意。我们的[跨渠道 opt-in 指南](/zh/blog/opt-in-consent-multichannel-campaigns/)说明了如何保存证据；以上不构成法律意见。 ## 推送和短信哪个更可靠？ 对于必须送达的消息，短信是更可靠的路径。推送取决于设备、应用、权限、网络连接、电池设置，以及 Google 或 Apple。 Google 明确表示 FCM 不保证送达：消息 ID 仅表示 FCM 已接受该消息，实际送达取决于设备状态和省电延迟等因素。如果设备离线，FCM 会存储消息并在重新联网后送达，直到存活时间到期（最长四周，这也是默认值），存活时间为零则会丢弃任何无法立即送达的消息。如果应用已被卸载，令牌就会失效，之后的发送都会失败。 短信也有自己的失败情形：过滤、未注册的发送方 ID、手机关机、号码变更。但它能给您网络的送达报告，并且不依赖应用。诊断步骤请阅读我们的[短信未送达](/zh/blog/sms-not-delivered-improve-delivery-rate/)指南。 对于时效性强的推送，请设置较短的存活时间，免得“您的骑手已到门口”的提醒明天才送达，并使用折叠键，让较新的更新取代较旧的。这两项都是我们[推送 API](/developers/push/) 中的字段。 ## 不同的消息该用哪个渠道？ 根据消息被错过会怎样来选择。 | 消息 | 更好的首选 | 原因 | |---|---|---| | 正在应用中登录的用户的验证码 | 推送或短信，另一种作为回退 | 推送对已登录用户很快；短信覆盖其他所有人 | | 没有应用的新用户的验证码 | 短信 | 无需应用，无需授权 | | 安全提醒（新设备、大额转账） | 短信，加推送 | 即使应用已关闭或被屏蔽也必须送达 | | 订单已发货、配送中 | 应用用户用推送；其他人用短信或 WhatsApp | 内容丰富、成本低，可深度链接到物流跟踪 | | 预约提醒 | 按客户偏好选推送或短信 | 错过风险低，被看到时价值高 | | 购物车遗弃 | 推送 | 成本低、内容丰富、可选 | | 促销 | 已 opt-in 的应用用户用推送；仅在有记录的 opt-in 时才用短信 | 避免为低意向的优惠支付短信费用 | | 重新激活流失用户 | 短信或邮件 | 推送无法触达已卸载应用的人 | 特别是验证码，请参阅我们关于 [OTP 消息](/zh/blog/otp-authentication-messages-guide/)和 [WhatsApp OTP 与短信 OTP](/zh/blog/whatsapp-otp-vs-sms-otp/)的指南。 ## 如何把推送和短信结合使用？ 先发推送，让短信来补救重要的消息。设计包含四个部分： 1. **渠道顺序：** 先推送，再短信。 2. **触发条件：** 推送在超时前未被打开或处理，或者没有可用的设备令牌。 3. **按消息类型设置超时：** 登录验证码可能只需几秒钟；付款提醒可能值得等一个小时。 4. **停止规则：** 如果用户已在应用中操作，则取消待发的短信。 对于低价值消息可以跳过短信，因为错过一条推送不会有任何损失。我们的[渠道回退策略](/zh/blog/channel-fallback-strategy/)一文说明了顺序和停止规则，[推送渠道](/zh/channels/push-notifications/)页面展示了推送如何与短信和 WhatsApp 一起处于同一个平台。送达状态通过统一的 webhook 格式返回（参见 [webhook](/developers/webhooks/)），您的系统因此可以判断是否需要回退。 回退短信应当能独立成文，并控制在一条之内。下面这条共 51 个字符，Unicode（中文不在 GSM-7 中），1 条（上限 70）：`【Souq Bites】订单 8842 付款失败。请打开应用更新银行卡：example.com/pay`。验证码版本共 45 个字符，Unicode，1 条：`【Souq Bites】您的登录验证码是 482915，5 分钟内有效。请勿向任何人透露。`中文短信一律按 Unicode 编码，单条 70 个字符，拆分后每段 67 个，因此请在[短信字符计数器](/zh/tools/sms-character-counter/)中预览。如果同一模板还要发英文版（纯 GSM-7，单条 160 个字符），要注意一个表情符号或弯引号就会让它变成 Unicode，上限降到 70。 ## 如何公平地衡量推送和短信？ 对两者使用同一套漏斗：发送、送达或已接受、打开或点击、转化。不要拿短信的“已送达”比例去比较推送的“已发送”数量，因为它们的含义不同。被 FCM“接受”的推送，不等于被用户看到的推送。 - **触达：** 目标用户中能接收每个渠道的比例。 - **送达：** 短信看运营商送达报告；推送看已接受，以及应用有记录时的已显示或已打开事件。 - **行动：** 链接点击、应用内事件和转化，归因于最后一次触达的渠道。 - **退订与卸载：** 投诉、STOP 回复、权限撤销，以及发送后的卸载。 - **每个结果的成本：** 渠道总成本除以完成的行动数，而不是每条消息的成本。 [消息 ROI 计算器](/zh/tools/messaging-roi-calculator/)和我们的[全渠道消息 ROI 商业论证](/zh/blog/omnichannel-messaging-roi-business-case/)展示了如何按结果来比较各渠道。 ## 实际案例：迪拜的外卖应用 “Souq Bites”（虚构）的应用中有一部分客户允许了通知，网页端的受众则更多。它通过推送发送订单状态更新，设置了较短的存活时间和折叠键，让最新状态取代之前的状态。新用户注册的验证码通过短信发送，因为新用户还没有应用权限。对现有用户，验证码通过推送发送；如果验证码在较短的超时内没有被使用，再从已注册的发送方 ID 发出短信。促销只通过推送发给允许通知并同意接收优惠的用户。可能已卸载应用的流失用户，只有在给出过短信同意的情况下，才会收到召回短信。 ## 常见错误有哪些？ - **把推送权限当作营销同意。** - **验证码只用推送发送**，让没有应用或未开通知的用户无法收到。 - **在推送和短信上同时发送相同的促销。** - **时效性强的消息仍使用默认的存活时间。** - **拿“FCM 已接受”与“运营商已送达”比较**，并据此宣布推送获胜。 - **所有消息都用短信**，为推送就能处理的提醒按条付费。 - **卸载后忽略失效的令牌**，导致推送发送数量虚高。 ## OmniChannels.ai 如何提供帮助 OmniChannels.ai 通过同一套 REST API 和平台发送推送通知和 A2P 短信，并支持 WhatsApp、RCS、邮件等其他渠道。推送支持按用户、令牌、主题和分群定向，支持模板、深度链接、折叠键和存活时间。短信通过 BroadNet 的运营商直连发送，渠道回退按用例配置，状态统一为一种 webhook 格式。请阅读[推送 API 文档](/developers/push/)，查看[推送通知渠道](/zh/channels/push-notifications/)，或[联系我们的开发者团队](/zh/developers/)。