最后更新:
商务邮件的最佳字数 - 主题行与正文的字数指南
邮件太长没人读，太短又传达不了意图。与 Slack 消息的写法一样，有意识地控制字数，才能写出确实能传达到对方的邮件。主题行会被收件端的显示宽度截断，正文则会因编码后的字节数而膨胀。本文就从这两个角度来谈字数该怎么定。
邮件的技术规范与字数的关系
规定邮件格式的 RFC 5322 (Internet Message Format，2008 年) 在第 2.1.1 节要求每行不得超过 998 个字符 (不含 CRLF)，并建议控制在 78 个字符以内。日文邮件常以 ISO-2022-JP 编码，简体中文邮件则以 UTF-8 进行 MIME 编码，因此看得见的字数与实际的数据大小并不一致。例如 UTF-8 的中文 1 个字符占用 3 字节，再经过 Base64 编码会膨胀约 1.37 倍 (4/3 倍，再加上折行部分)。也就是说，1,000 字符的正文约为 4.1 KB 的数据量。同一个 RFC 并未限制主题行 (Subject 头) 本身的字数，但正如邮件通讯的写法中提到的，接收端客户端的显示宽度才是实质上的约束。
编码方式与实际数据大小的比较
邮件的主题行与正文在发送时会经过编码处理，数据大小随之变化。即使是同样的文本，编码方式不同大小也差异很大，在考虑邮件服务器的容量限制或头部大小上限时这是重要的知识。
| 编码方式 | 每 1 个字符 | 20 个日文字符的主题行 | 主要用途 |
|---|---|---|---|
| ISO-2022-JP (Base64) | 约 2.7 字节 (2 字节 × 4/3) | 82 字节 | 日文商务邮件 |
| UTF-8 (Base64) | 约 4 字节 (3 字节 × 4/3) | 92 字节 | 国际邮件、Gmail |
| UTF-8 (Quoted-Printable) | 约 9 字节 (3 字节 × 3) | 192 字节 | 部分邮件客户端 |
主题行头部按 RFC 2047 (MIME Part Three，1996 年) 的编码字 (encoded-word) 形式 (=?charset?encoding?encoded-text?=) 编码。上表的数值，就是把这个标识符与字符集切换控制都算进去之后的实际头部长度。例如日文的"会議の件"(4 个字符)，以 ISO-2022-JP + Base64 编码是 =?ISO-2022-JP?B?GyRCMnE1RCRON28bKEI=?= 的 38 字节，以 UTF-8 + Base64 编码则是 =?UTF-8?B?5Lya6K2w44Gu5Lu2?= 的 28 字节。
短主题行反而 UTF-8 更小，这一点不太直观，原因是 ISO-2022-JP 要在日文部分前后插入字符集切换控制，而且字符集名本身也更长。这份固定的额外开销与主题行长短无关，因此大约以 12 个字符为界，每字符 2 字节与 3 字节的差额才会反超，之后 ISO-2022-JP 才更小。另外 RFC 2047 规定单个编码字不超过 75 个字符、含编码字的头部行不超过 76 个字符，所以较长的主题行会被拆成多个编码字，并以 CRLF + 空格折行。简体中文无法用 ISO-2022-JP 表示，实际上只有 UTF-8 一个选择。
实务上的影响是：遇到无法正确重组这种折行的较旧邮件服务器或网关时，较长的主题行会被截断或产生乱码。UTF-8 + Quoted-Printable 时，50 个字符的主题行光编码后的本体就达到约 450 字节，考虑安全余量，主题行控制在 30 个字符以内在技术上也是合理的。
邮件主题行的最佳字数
这里首先要明白的是："主题行能显示多少个字"并不存在固定值。桌面端邮件软件的收件列表列宽由用户自由调整，同一个软件能显示的字数也会差很多。也就是说，实际上定下下限的是屏幕宽度固定的手机与可穿戴设备一侧。
| 邮件客户端 | 主题行显示宽度的决定方式 | 预览文本 |
|---|---|---|
| iPhone 邮件 (竖持) | 屏幕宽度固定，比桌面端短得多 | 主题行下方 1~2 行 |
| Gmail (移动端) | 屏幕宽度固定，比桌面端短得多 | 显示在主题行下方 |
| Gmail (桌面端) | 取决于窗口宽度，主题行与预览共用同一行 | 在主题行之后以灰色显示 |
| Outlook (桌面端) | 取决于收件列表的列宽，拉宽就能显示更长 | 默认不显示 (可在设置中启用) |
| Apple Mail (桌面端) | 取决于列宽，可设置为 2 行显示 | 显示在主题行的下一行 |
| Apple Watch | 屏幕宽度固定，是最短的 | 无 |
主题行的推荐长度为 15~25 个中文字符。将核心信息放在前 15 个字符内，确保在任何设备上都能传达意图。与推送通知的字数限制一样，邮件主题行也应把重要关键词放在开头 15 个字符以内。
为什么是 15~25 个字符？桌面端的收件列表基本能读完全文，而手机上会从末尾开始被截掉。收在 15~25 个字符，桌面端能显示全文、手机上也能看到事项的核心，是"最大公约数"的长度。商务邮件同样经常先在手机上做初步判断，以这个长度为基准比较稳妥。
定字数时，与其盯着打开率这类结果指标，不如从"被截断之后还剩下什么"来考虑，判断会容易得多。按字数区间整理显示情况如下。
| 主题行字数 | 手机列表中的显示情况 | 容易出现的问题 |
|---|---|---|
| 不足 10 个字符 | 能显示全文 | 像"联系一下"这样无法特定事项，判断不出优先度 |
| 10~19 个字符 | 能显示全文 | 项目名与事项容易漏掉其中一个 |
| 20~30 个字符 | 大致能显示全文，部分环境下末尾略有截断 | 基本没有 (把事项放在开头，即使被截也能传达) |
| 31~40 个字符 | 末尾开始被截掉 | 把期限或请求内容放在末尾就会消失 |
| 41 个字符以上 | 后半大幅被截 | 开头若是套话寒暄或公司名，事项完全看不到 |
由此可见，本质不在于长度本身，而在于"被截断之后剩下的部分"。即使主题行有 40 个字符，只要前 15 个字符已把事项说完，实务上就不会有困扰。反过来，即使只有 25 个字符，开头被"【○○○○股份有限公司】"占满的话，手机上也看不出是什么事，只会被往后放。
预览文本的优化
在 Gmail 与 iPhone 的邮件应用中，主题行之后会把正文开头作为"预览文本"显示。这是在打开邮件之前，还能补足主题行说不完的信息的最后一个说明位。
很多商务邮件的正文开头是"您好，我是 ○○ 部的 △△"这类固定寒暄，导致这个位置被寒暄占满、看不到事项。只要把结论或期限写在第 1 句，主题行与预览合起来就能传达全貌。
HTML 邮件可以用 <div style="display:none; max-height:0; overflow:hidden;"> 设置隐藏的预览头文本，这样就能独立于正文开头来控制专用的预览文字。但要注意：如果预览头之后没有插入足够数量的不可见空白字符 (‌ 的重复)，正文开头会接在预览头后面一起显示出来。
预览文本能显示多少，也同样交由客户端决定。Gmail (桌面端) 中主题行与预览共用同一行，因此主题行越短预览区域越宽。手机上则收在主题行下方 1~2 行的框内，比桌面端短。想让它在任何环境下都发挥作用，就把最重要的信息放在预览的第 1 句，其后即使没被读到也仍然成立。
邮件正文的最佳字数
商务邮件正文的适当长度因目的而异。以下是从收件人阅读时所花的功夫倒推出来的实务参考。
| 邮件类型 | 推荐字数 | 收件人的阅读方式 |
|---|---|---|
| 简单确认/回复 | 50~100 字 | 不用滚动就能读完，当场处理 |
| 业务联络 | 200~400 字 | 在手机上也能一口气读完的上限附近 |
| 提案/报告 | 400~800 字 | 需要静下心来读，容易被往后放 |
| 初次联系 | 150~300 字 | 先看自我介绍与目的，再决定是否细读 |
| 详细报告书 | 800~1,500 字 | 在邮件正文里会被跳读 (宜分离到附件或资料) |
需要注意的是，这些数字只是参考值，并不是"一超过就不会被回复"的界线。
长邮件之所以被敬而远之，原因不在字数本身，而在于"自己该做什么"得在正文里找。同样 800 字，开头就写明请求与期限的负担很小；而铺陈完经过、请求却放在末尾的写法则读不到最后。眼看要变长时，与其先删，不如先试着把请求移到开头、把细节挪到后面。
按邮件类型设计字数
商务邮件、营销邮件、事务性邮件所需的字数存在根本差异。
| 邮件类型 | 主题行 | 正文 | 设计要点 |
|---|---|---|---|
| 商务邮件 (公司内) | 15~25 字符 | 100~500 字符 | 用最短篇幅说清事项 |
| 商务邮件 (公司外) | 20~30 字符 | 200~800 字符 | 兼顾礼貌与简洁 |
| 营销邮件 | 15~25 字符 | 300~600 字符 | 缩短到 CTA 的路径 |
| 事务性邮件 | 20~35 字符 | 100~300 字符 | 必要信息不漏且简洁 |
| 邮件通讯 (纯文本) | 20~30 字符 | 1,000~2,000 字符 | 抑制滚动量 |
| 邮件通讯 (HTML) | 20~30 字符 | 500~1,000 字符 | 图片与文字的平衡 |
提升打开率的主题行写作技巧
- 前置关键信息：将最重要的词放在主题行开头。"【紧急】明日会议时间变更"比"关于明日会议时间变更的通知"更有效。在开头加上【】分类标签，收件人能瞬间判断优先度。
- 使用具体数字："3 个改善方案"比"改善方案"更能吸引注意。
- 避免全大写和过多感叹号：这些会触发垃圾邮件过滤器，也给人不专业的印象。
- 个性化：在主题行里带上收件人姓名、公司名或项目名，对方能一眼确认"这是发给自己的邮件"。
邮件正文的结构技巧
- 结论先行：在邮件开头明确目的和请求。忙碌的收件人可能只读前几行，理想的做法是用开头 2 行写明"希望对方做什么""什么时候之前需要"。
- 一封邮件一个主题：多个主题混在一封邮件中会降低回复率。需要讨论多个话题时分开发送。
- 使用列表和分段：长段落难以阅读。用编号列表或项目符号整理要点，每段控制在 3~4 行以内。桌面端 3 行的段落在移动端会折行成 6~7 行。
- 明确行动项：在邮件末尾清楚说明需要对方做什么、截止日期是什么时候。
专业人士实践的字数技巧
每天处理数十封邮件的商务专业人士，会活用以下技巧。
- 追求"只看主题行就完结的邮件"。像"【报告】A 公司拜访改为 3/10 14 时"这样只看主题行就能传达事项的邮件，连打开都不需要，最能节省收件人的时间。
- 应用"BLUF (Bottom Line Up Front)"原则。这一源自军事用语的手法是先写结论、再补背景与细节。用"结论：请批准 ○○。理由：因为 △△。"的形式，再忙的对方也能用最初 2 行掌握事项。
- 意识"5 句规则"。把正文控制在 5 句以内为目标，自然会写出简洁且要点明确的邮件。5 句写不完时，就是该考虑改用电话或当面说明的信号。
- 回复邮件时把引用降到最低。全文引用只会增加收件人的滚动量。只引用必要部分并在其后作答的"部分引用"更高效。
常见失误与对策
- 主题行过于模糊："关于上次的事"这样的主题行无法传达内容，容易被忽略。应具体写明"关于 XX 项目报价单的确认"。只写"辛苦了"这类寒暄的主题行，收件人无法判断优先度，最坏情况会被误认为垃圾邮件。
- 正文过长：超过 800 字的邮件应考虑改用附件或会议。超过 2,000 字、不滚动就读不完的邮件，重要信息会被埋没。邮件正文只放摘要和行动项。
- 正文不足 50 字：只回"了解""知道了"看似高效，但对部分收件人会显得冷淡、被轻视。对公司外的客户或上级，加一句话就能大幅改变印象。
- 缺少明确的行动请求：不清楚需要对方做什么的邮件，回复率极低。
- 主题行与正文不一致：主题行写"请确认"而正文只有报告、没有写明确认事项，收件人会在期待与实际内容的落差中混乱，导致处理延迟。
- 回复全部的滥用：不必要的"回复全部"会造成信息过载。只在确实需要所有人知道时使用。
HTML 邮件与纯文本邮件的字数差异
即使内容相同，HTML 格式与纯文本 (纯文本) 格式的数据大小也大不相同。HTML 邮件包含装饰标签、CSS、图片引用等，数据量可能达到纯文本的 3~10 倍。
实务上要注意：HTML 邮件里看得见的字数与源码字数会背离。例如"加粗的文本"在屏幕上是 5 个字符，但 HTML 源码写成 <strong>加粗的文本</strong> 就是 22 个字符。管理营销邮件字数时，应以显示文本的字数为准。
另外，以 multipart/alternative 同时包含 HTML 与纯文本的邮件，数据量单纯地接近 2 倍。邮件服务器的容量上限因环境而异，由收发双方的服务器设置决定，没有可以一概而论的数值。真要压缩体积时，先从图片 (尺寸与张数) 入手比削减文字有效得多，因为文字部分即使写满几千个字符也只有数 KB。
容易忽略的边缘情况
思考邮件字数时，除正文外还需要综合管理以下要素。
- 签名的字数：签名通常为 3~5 行 (100~200 个字符)，但加上部门、职位、电话号码、URL 后可能超过 300 个字符。正文 200 个字符、连签名 500 个字符时，收件人的体感就是"长邮件"。签名应压到必要的最小限度。
- CC/BCC 与头部大小：CC 中含大量地址时，To/CC 头部会变得很长，并按 RFC 5322 的规定以 CRLF + 空白折成多行。这本身通常不会导致投递失败。实务上的影响在别处：收件人一按"全部回复"就会把所有地址都带上，往来几轮之后头部与引用一起膨胀。发给 10 人以上时改用邮件列表，或把不需要往来的地址移到 BCC。
- 附件文件名的字数：较长的中文文件名经 MIME 编码后会膨胀，能容纳到多长取决于服务器与客户端，没有可以照抄的上限值。稳妥的做法是文件名只保留"内容 + 日期 + 版本"这类最小信息，把说明写进正文而不是塞在文件名里。
- 回复引用的累积：来回多次的邮件线程中，引用累积会让整封邮件达到数万字符。每封邮件的大小上限同样由收发双方的服务器设置决定，超过时会被退回。定期整理引用、只留下必要的往来部分比较安全。
含表情符号的主题行的编码问题
营销邮件常用表情符号让主题行更醒目，但技术上有陷阱。表情符号以 Unicode 的代理对或组合字符序列表示，编码时的大小比普通字符更大。
例如"🎉"(派对彩带) 在 UTF-8 中为 4 字节，Base64 编码后约占 8 字节。进一步地，改变了肤色的表情符号 (例如 👋🏻) 由基础表情符号与肤色修饰符这 2 个码位构成 (不使用 ZWJ)，在 UTF-8 中合计 8 字节。国旗表情符号 (例如 🇯🇵) 也由 Regional Indicator Symbol 组合而成，占 8 字节。
问题不只是大小。ISO-2022-JP 无法表示表情符号，因此含表情符号的主题行会被强制以 UTF-8 编码。若接收端客户端以 ISO-2022-JP 为前提，主题行就有乱码的风险。特别是较旧世代的邮件软件与部分运营商邮箱，表情符号会被替换成"□"或"?"。商务邮件应避免使用表情符号，营销邮件也要在考虑收件人邮件环境后再判断。
移动端优化
超过 60% 的商务邮件在移动设备上首次打开。移动端优化要点：
- 主题行控制在 20 字符以内
- 正文前 2~3 行包含核心信息
- 段落保持短小 (每段 2~3 句)
- 避免复杂的表格和格式
各邮件客户端的显示特性
同一封邮件在不同客户端的显示差异很大。Gmail 会在主题行后用灰色显示预览文本，主题行越短预览区域越宽。Outlook 桌面版默认不显示预览文本，只能凭主题行判断。Apple Mail 可以设置为多行显示，实际能看到多少取决于收件人一侧的设置。综合这些差异，主题行 20~30 个字符 + 正文开头写要点的结构，是在任何客户端都能有效发挥作用的最优解。
总结
商务邮件的效果取决于字数的精准控制。主题行 15~25 字符、正文 200~400 字符是大多数场景的最佳范围。结论先行、一邮一题、明确行动项是提升回复率的三大原则。理解 RFC 的技术规范、编码方式带来的数据大小差异以及各客户端的显示特性之后再设计字数，就能写出在任何环境下都确实传达到的邮件。发送前使用字符计数器确认字数，确保邮件在各种设备上都能完整显示。