最后更新: 2026-09-04

推送通知的字数限制｜iOS 与 Android 完整指南

推送通知实际可见的字数大致为：iOS 标题约 50 字、正文约 178 字 (锁屏。横幅约 80 字)，Android 标题 65 字、正文约 45 字 (折叠时。展开时为 240 字)。由于会随操作系统和显示场景大幅变化，务必传达到的信息建议控制在标题 20 字以内、正文 40 字以内。

推送通知与 LINE 消息一样，是移动通信的主要渠道，但其显示字数限制非常严格。这些限制不仅源于操作系统和设备的显示区域，还涉及 APNs (Apple Push Notification service) 和 FCM (Firebase Cloud Messaging) 的 payload 大小等技术层面的约束。正确理解这些限制，在有限的字数内最大化传达效果，是推送通知设计的核心课题。

APNs 与 FCM 的 payload 限制 - 字数限制的技术背景

推送通知字数受限的根本原因在于承载通知数据的 payload 大小上限。APNs 的 payload 上限，在当前使用的 HTTP/2 接口中为 4,096 字节 (4 KB)。在此之前的旧二进制接口时代，上限只有 2 KB，是现在的一半；该旧接口已于 2021 年 3 月停止服务，因此现在设计通知时以 4 KB 为前提即可。FCM 的通知消息同样为 4,096 字节上限，而数据消息最大可发送 4,000 字节。

payload 中不仅包含标题和正文，还包括声音指定、角标数、自定义数据 (深度链接 URL、活动 ID 等)。由于采用 JSON 格式编码，中文等多字节字符在 UTF-8 编码下每个字符消耗 3 字节。也就是说，即使在 4 KB 的 payload 中全部填入中文，理论上限也仅约 1,365 个字符，扣除元数据和自定义数据后，实际可用于文本的容量不到其一半。

各操作系统的字数限制

除了 payload 的技术上限外，各操作系统的 UI 能显示的字数也有限制。下表汇总了主要平台的显示字数限制。

在看表之前需要先说明一点：各家的官方文档是以「行」来规定显示量的，并没有规定字数。例如 Android 的官方文档只写明折叠状态下的正文会被截断到一行以内，并未给出可显示的字符个数。下表是以 2026 年 8 月的实际显示情况、系统标准字号为前提整理出的实践参考值，其中也包含官方文档并未明确记载的项目。因此请不要把表中的数字当作官方保证的绝对值，而是把它当作「哪个显示位置更窄、哪个更宽」这种相对关系来读；实际投放前，仍应在自己面向的机型上确认真实的截断位置。

值得注意的是，同为 iOS，锁屏、横幅和通知中心的显示字数差异很大。横幅通知仅在屏幕顶部短暂显示，正文限制在约 80 字；而锁屏可显示约 4 行，最多可阅读约 178 字。在通知中心中，长按可展开全文，因此 payload 上限内的文本均可查看。

按通知的种类分配字数 - 确认类与引导类

字数该怎么分配，与其按行业去套模板，不如先分清这条通知属于哪一类。推送通知大致可以分成两类：一类是「确认类通知」，把已经发生的事实告知用户，例如到账、发货、预约成立；另一类是「引导类通知」，希望用户打开应用去做点什么，例如活动开始、推荐内容、优惠即将结束。两类通知里用户最先想看到的东西不同，因此该写进标题的内容、正文可以省略到什么程度也不同。下表按几个角度对比这两类通知，作为分配字数时的判断依据。

实际运营中最容易出问题的，是两类通知共用同一套模板。模板往往是先照着引导类通知做出来的，于是开头带上了应用名和固定的招呼语；等到把它拿去发确认类通知时，用户真正想看的金额、时间和对象就被挤到了折叠显示的外面，只剩下一句谁都看不懂的开场白。反过来，把确认类的极简模板直接用在引导类通知上，用户看完也不知道点进去能做什么，就只会划掉。因此模板至少要按这两类分开准备，并且各自确认「折叠状态下能看到的部分是否已经说明了要点」。

正文与商务邮件一样要求简洁，但需要比邮件更短，即使省略细节也要确保意思完整。折叠显示时只能看到 1-2 行，因此将最重要的信息浓缩在开头 40 字内至关重要。

为什么各操作系统的字数不同

iOS 横幅通知限制为 2 行显示。通知这种东西，本质上是打断用户手上正在做的事，因此它的显示面积是被有意做小的，只留下足以让用户判断「现在要不要中断手上的事」的信息量。iOS 16 之后，锁屏通知显示被集中到底部，优先保证壁纸的可见性，显示面积进一步受限。

而 Android 的展开显示，则符合渐进式披露 (progressive disclosure) 这种界面设计思路。折叠时用 1 行传达概要，用户感兴趣时可展开阅读详情，这是一种两阶段设计。Android 13 之后，通知权限改为 opt-in 方式，与 iOS 一样需要用户明确授权。这一变化导致 Android 的通知许可率也呈下降趋势，向已授权的宝贵用户发送高质量通知变得更加重要。

富媒体通知的字数限制与设计注意事项

iOS 10 之后的 Notification Content Extension 和 Android 的 BigPictureStyle / BigTextStyle 支持包含图片、按钮和轮播的高级通知。但富媒体通知的字数约束与纯文本通知不同。

• 图片通知的文本区域缩减: iOS 中附加图片后，正文可显示的区域会被图片挤占，能读到的字数比纯文本通知更少。具体少多少随机型和显示位置而变，并不是一个固定的比例，因此使用图片时要把文本再缩短一层。此外，图片可能因为网络状况而没能加载出来，也有用户在省流量的设置下看不到图片，所以文案要按「只剩文字时意思是否依然成立」来写，不要把要点只放在图片里
• 操作按钮的影响: Android 的官方文档写明，一条通知最多可以提供 3 个操作按钮；iOS 一侧能同时显示的按钮数量同样很少，因此请以「只能放少数几个」为前提来设计。按钮标签可显示的字数上限，官方文档并未给出具体数值，但标签过长会被截断是确定的，因此控制在 5-8 字 (如"立即购买""查看详情") 最为实用
• 对 payload 的影响：图片 URL 和操作按钮的定义会消耗 payload 空间，导致可用于文本的容量减少。图片通常通过 URL 引用 (APNs 的 mutable-content + Notification Service Extension) 方式分发，图片数据本身不包含在 payload 中

可穿戴设备上的显示 - 容易被忽视的限制

Apple Watch 和 Wear OS 设备的字数限制比智能手机更为严格。Apple Watch 的 Short Look (收到通知后显示数秒的画面) 仅显示应用名称和部分标题，正文需要切换到 Long Look 才能阅读。Long Look 中由于屏幕尺寸限制，正文在约 60 字处就会换行。

Wear OS 以通知卡片形式显示，可通过滚动查看全文，但首先映入眼帘的是标题和正文开头约 30 字。可穿戴设备用户通常在移动或运动中查看通知，因此需要仅凭标题就能把握内容的设计。针对可穿戴设备优化通知时，标题控制在 20 字以内、正文开头 30 字内放置核心信息最为有效。

Web 推送通知的限制

Web 推送通知因浏览器和操作系统的组合不同，显示效果差异很大。Chrome、Firefox、Safari 各自可显示的字数和外观都不同，因此按最严格的环境来设计最为安全。

Safari 从 macOS Ventura 开始支持 Web 推送通知，但 iOS 上的 Safari 仅在 iOS 16.4 及以上版本且作为 PWA (添加到主屏幕的应用) 时才支持。普通浏览器标签页无法发送 Web 推送，因此对 iOS 用户的触达存在限制。

一般来说，标题控制在 30 字以内、正文控制在 80 字以内，就能在主要浏览器和操作系统的组合中不被截断地显示。设置图标和徽章图片的意义，在于让用户一眼就能认出这条通知来自哪个网站。Web 推送与应用通知不同，用户往往同时允许了多个网站，如果只有文字，用户就要先读完标题才能想起是谁发来的；反过来说，图标本身并不能替代文案，标题里仍然要写清主体和要点。

A/B 测试的设计方法 - 通知文案的优化流程

推送通知的 A/B 测试需要与邮件营销的 A/B 测试不同的方法。通知一旦发送就无法撤回，用户的反应会在几分钟内集中出现，因此测试设计需要考虑以下几点。

• 测试对象的隔离：每次测试只改变一个要素。如果测试标题字数，则正文、发送时间和图片保持不变。同时改变多个要素将无法判断哪个要素影响了结果
• 确保样本量：要获得统计显著性结果，每个变体至少需要分配 1,000-2,000 名用户。用户数较少的应用可通过多次测试积累趋势
• 控制时间段: A/B 两组在相同时间段发送。早晨和晚上的打开率差异很大，发送时间的偏差会扭曲测试结果
• 选择衡量指标：不仅追踪打开率 (点击率)，还要追踪通知带来的转化率、应用内停留时间和通知关闭率。即使打开率高，如果通知关闭率上升，长期来看是负面的

个性化通知的字数策略

个性化通知需要插入用户名或动态数据，因此需要预先计算固定文本的字数。例如，模板"{用户名}，您的购物车中还有商品"中，整体字数会因用户名长度而变化。

中文的用户名往往几个字就写完了，但英文名、昵称或店铺名有可能超过 10 个字符。设计模板时，应确保即使使用最长的用户名，标题也不会被截断，因此固定文本部分应控制在 15 字以内，为动态部分预留约 10 字的余量。

比字数更容易被忽略的，是插入失败时的样子。用户名、商品名、金额这些动态部分都来自另一套数据，取不到值的情况一定会发生，届时通知里可能出现「，您的购物车中还有商品」这样开头就缺一块的句子，甚至直接把 {用户名} 这样的占位符发出去。因此模板要先准备好取不到值时使用的替代文案 (例如省掉称呼直接从要点写起)，并在发送前用两种极端数据各确认一次显示效果：一种是最长的值，看标题会在哪里被截断；另一种是空值，看句子是否仍然读得通。只要这两种都成立，剩下的普通数据基本不会出问题。

防止通知疲劳 - 发送频率与字数的关系

推送通知"不要发送过多"极为重要。一天内多次发送通知，会增加用户关闭通知或卸载应用的风险。而关闭通知这件事，从发送方来看几乎是不可逆的：用户在系统设置里关掉之后，应用无法自行恢复，只能等用户哪天主动回到设置里改回来。更麻烦的是，这个损失在数据上很难被发现。被关掉通知的用户不会给出任何反馈，通知照样算作发送成功，只是不再显示出来。如果只盯着打开率，就察觉不到分母 (真正还能看到通知的人数) 正在慢慢减少，甚至因为留下来的都是对通知比较耐受的用户，打开率反而可能变好看。因此除了打开率，还应该定期观察允许通知的用户数本身是在增加还是在减少。

发送频率与字数存在相关性。频率较高时 (每天 1 次以上)，每条通知应尽量简短 (标题 15 字以内、正文 30 字以内)，降低信息密度以减轻用户的认知负担。而每周 1-2 次的发送频率下，稍长的正文 (60-80 字) 传达详细信息也不容易引起通知疲劳。

不同类型的通知适合的频率也不同。交易通知 (订单确认、配送状态) 需要实时性，不受频率限制；而促销通知对大多数应用来说，每周 2-5 次是合适的上限。通过为每个用户设置通知频率上限 (频次控制)，控制一定时间内的发送数量，可以系统性地防止通知疲劳。

iOS 与 Android 通知许可率的差异

两个平台在「怎样才算获得许可」上走过了不同的路。iOS 从一开始就要求用户明确同意之后才能发送推送通知；而 Android 在 12 及更早的版本里，装上应用就默认可以发送通知。Android 13 之后改为需要 POST_NOTIFICATIONS 权限的明确授权，这一点与 iOS 变成了同样的做法。结果是，现在无论哪个平台，能收到通知的都只是主动同意过的那部分用户，Android 的许可率也随之呈下降趋势。

iOS 应用中，通知许可请求的时机和措辞极为重要。不要在应用首次启动时立即请求许可，而是在用户理解通知价值之后 (首次购买后、收藏后等) 再请求的"预许可"模式更为有效。在许可请求前通过应用内对话框说明通知的好处，仅在用户选择"接收通知"时才显示系统许可对话框。之所以要多这一道手续，是因为系统的许可对话框实际上只有一次机会：用户一旦点了拒绝，同一个对话框就不会再自动弹出，之后只能引导用户自己进入系统设置页面去打开，而愿意走完这几步的人非常少。与其在用户还不明白通知有什么用的时候把这唯一一次机会用掉，不如先用应用内的对话框确认意愿，再把系统对话框留给已经想要接收通知的人。

常见的失败模式

• 深夜发送通知导致用户信任流失：晚上 10 点至早上 7 点的通知不仅打扰用户睡眠，还直接导致通知关闭或应用卸载。设置考虑时区的发送计划是必须的。面向全球的应用需要获取用户的本地时区，在各地区的合适时间段进行推送
• "通知""重要"等模糊标题导致打开率低迷：缺乏具体性的标题会被用户判断为"又是广告"而忽略。用户是在锁屏上用一瞬间决定要不要点开的，此时唯一的判断依据就是标题里有没有与自己相关的信息。写进具体的数字和截止时间 (如"今日 18 点前 5 折")，就是把这个判断依据交给用户，而不是让用户点开之后再自己去找
• 向所有用户群发相同通知：不做分群的群发对不相关的用户来说只是噪音。根据用户属性 (购买历史、应用使用频率、地区) 进行分群，向各群组发送优化后的通知，可同时提升打开率和转化率
• 未设置深度链接导致跳转到首页：点击通知后打开应用首页是 UX 的失败。通知里写的内容与打开后看到的画面对不上，用户就得自己重新去找那件商品或那个活动，这一步往往就是放弃的地方。直接跳转到与通知内容对应的具体页面 (商品详情、活动页面等)，是把这段多余的寻找过程去掉

专业人士实践的通知技巧

• 用富媒体通知创造视觉冲击：图片可以在用户读文字之前就传达出「这是什么类型的通知」，对商品、地图、活动主视觉这类本来就靠画面说明的内容尤其有效。代价是正文能显示的字数会变少，而且图片未必加载得出来，因此必须同时设计好只剩文字时的版本 (仅文本通知)，让意思在没有图片时依然完整
• 为每个用户优化发送时间：不是在相同时间段向所有用户发送，而是根据每个用户过去的应用使用模式推测其最活跃的时间段，逐一调整发送时间。哪个时间段合适无法照搬别人的结论，唯一可靠的依据是自己的投放记录：把过去的发送按时间段拆开，比较各时段的打开率与通知关闭率，就能看出本应用的用户在什么时候愿意看通知。生活节奏的个体差异很大，因此在掌握整体倾向之后，进一步做到用户级别的调整是理想方案
• 利用通知渠道控制优先级：使用 Android 8.0 之后的通知渠道功能，按通知类型 (交易、促销、新闻等) 分离渠道。用户可以按渠道切换通知的开关，从而避免重要的交易通知与促销通知一起被关闭的风险

总结

推送通知的字数限制源于 APNs/FCM 的 payload 上限和各操作系统的 UI 设计两方面。不仅 iOS 和 Android 的显示字数不同，锁屏、横幅、通知中心、可穿戴设备等显示场景也会带来很大差异。要确保信息传达，标题控制在 20 字以内、正文控制在 40 字以内最为安全。按通知的种类 (是告知已发生的事实，还是引导用户去做某件事) 来分配字数、通过 A/B 测试持续改进、在使用个性化时把插入失败的情况也一并设计好，是把通知的效果发挥到最大的关键。编写通知文案时，请使用字符计数器确认字数后再发送。