新Gmail UI下使用Users.drafts.send API发送给自己的邮件无法加载问题

你遇到的这个问题我之前在开发邮件相关工具时也碰到过，核心原因大概率是新Gmail UI对邮件线程的解析逻辑比旧UI更严格，再加上请求格式的小细节疏忽导致的。下面是针对性的排查和解决方案：

一、先修正Multipart请求的格式错误 #

看你提供的请求载荷，发现multipart边界符和内容格式有明显问题，这是新UI解析失败的常见诱因：

• 边界符（比如--foobar）前后不能有多余空格，你写的-- foobar是错误格式
• 每个MIME部分的Content-Type头和实际内容之间必须空一行

修正后的正确格式示例：

--foobar
Content-Type: application/json; charset=UTF-8

{ "id":"r7236859678058445300","message": {"threadId":"1638e05ec3ad551b"} }
--foobar
Content-Type: message/rfc822

MIME-Version: 1.0
Date: Wed, 23 May 2018 13:22:22 -0400
Message-ID: <CAEygFSf=hnH-dTUeXDC3Z0FKDLB_C94ej4FNK-6NO6yOeGRpJA@mail.gmail.com>
Subject: Test
From: Tom <Tom@testemail.com>
To: Tom <Tom@testemail.com>
Content-Type: multipart/alternative; boundary="00000000000028c4a8056ce2c7eb"

--00000000000028c4a8056ce2c7eb
Content-Type: text/plain; charset="UTF-8"; format=flowed; delsp=yes

dsfsdfsdf
--00000000000028c4a8056ce2c7eb
Content-Type: text/html; charset="UTF-8"

<div dir="ltr">dsfsdfsdf</div>
--00000000000028c4a8056ce2c7eb--
--foobar--

二、排查ThreadId的使用逻辑 #

新Gmail UI对线程的匹配规则更严格，当你指定threadId时：

• 确保这个threadId对应的线程确实存在，且线程内的历史邮件包含你自己作为收件人
• 如果不需要关联到特定线程，直接移除message中的threadId参数，测试是否能正常显示邮件
• 若必须关联线程，保证当前邮件的主题、收件人信息和目标线程的历史邮件完全匹配（Gmail默认通过「主题+收件人组」关联线程）

三、其他排查方向 #

1. 确保Message-ID唯一性：如果你的Message-ID和邮箱中已存在的邮件重复，新UI可能会出现线程匹配混乱，建议生成全新的唯一Message-ID再测试
2. 去掉Draft ID测试：尝试在JSON部分只保留message字段，去掉id参数，避免Draft状态带来的额外逻辑干扰
3. 先测试无附件场景：先发送不带大附件的邮件，确认新UI能正常加载后，再逐步添加附件，排查是否是附件的MIME格式导致解析失败

总结 #

优先修正Multipart请求的格式问题，这是最容易忽略也最可能解决问题的点；如果格式修正后仍有问题，再排查ThreadId的使用逻辑。按照这个步骤测试，应该能解决新UI下的对话加载异常。

内容的提问来源于stack exchange，提问作者Kate