文件在磁盘上的大小只是生成消息的一部分。MIME 请求头和 base64 编码会增加开销，因此一个在服务商公布限制内的文件仍然可能使消息超出大小限制。
为什么附件在传输中会变大？
Base64 编码会在添加换行符和 MIME 请求头之前，将二进制文件的大小增加约三分之一。邮件将编码后的文件作为 MIME 部分传输，与正文和请求头一起发送。
例如，一个 12 MB 的二进制文件在加上换行符、请求头和正文之前，经过 base64 编码后大约变为 16 MB。请将此作为估算值，而非服务商限制。
应该使用哪个限制？
使用发送服务、收件人服务商和中间路径中最小的限制。各服务商发布的限制不同，且可能随时更改。请链接到服务商的当前限制，而不是硬编码一个通用数字。
如果文件接近限制，请改用经过身份验证的下载链接。消息本身保持较小。您可以独立于邮件来设置过期或撤销访问权限。
| 边界 | 限制对象 | 示例后果 |
|---|---|---|
| 附件上限 | 单个文件或附件字段 | API 拒绝该项 |
| 整体消息上限 | 正文、请求头和编码后的附件 | 发送方拒绝生成的消息 |
| 云链接传输 | 关联的下载服务 | 收件人遵循单独的访问策略 |
Gmail 个人帮助说明附件总限制为 25 MB。工作区管理员可以为工作和学校账户设置不同的限制。请将两者都视为特定于服务商的值。
API 应如何处理大文件？
在发送前检查编码后的消息大小。拒绝或将超大附件替换为明确的下载链接。告知用户是哪个文件导致了该决定。不要重试未更改的超大消息。
保持附件名称和内容类型准确。收件人的服务商可能会因消息总大小、被阻止的文件类型或应用于链接的策略而拒绝消息。
Bird 如何处理附件？
在 POST /v1/email/messages 请求中设置 attachments 数组。查看附件指南了解 Bird 当前的生成消息额度。超大的 HTTP 发送会返回 413。将原始附件内容控制在文档规定的额度以下，以便正文和 MIME 封装能够容纳。
简而言之
- 限制涵盖编码后的消息、正文、请求头和附件。
- Base64 会将二进制文件的大小增加约三分之一。
- 检查投递路径中每个服务商的限制。
- 下载链接可以避免大文件的附件大小限制失败问题。