使用Graph API LargeFileUploadTask发送带大附件邮件时出现内部错误

1. 体积超限：微软365邮件100MB的大小限制为最终传输的总大小，包含邮件正文、附件元数据、以及附件Base64编码带来的33%左右的体积膨胀，并非仅计算附件原始大小。你测试用的10个10MB文件原始总大小为100MB，编码后总大小超过130MB，远超出限制，上传到第3~4个附件时总占用触碰到服务端阈值，因此触发无详细信息的内部错误。
2. 逻辑错误：代码中附件上传方式的判断条件写错，原本应该根据附件内容大小选择上传方式，实际写的是判断attachment.Body.Length < 3，字段和阈值均不正确，导致大量本该直接上传的小文件也走了大文件上传会话，额外增加了元数据开销，进一步放大了超限概率。
3. 配置冲突：创建草稿时连续调用两次WithMaxRetry，配置逻辑冲突，可能导致请求重试不生效，放大了上传失败的概率。

• 修正上传方式判断逻辑：将判断条件改为attachment.Contenu.Length < 4 * 1024 * 1024，4MB是Graph API单附件直接上传的官方上限，避免不必要的大文件上传会话开销。
• 提前校验总附件大小：上传前先统计所有附件的原始大小总和，控制在70MB以内，预留足够的编码和元数据占用空间，避免卡阈值。
• 优化大文件上传配置：将分块大小maxChunkSize调整为3MB（3 * 1024 * 1024），分块大小为3MB的倍数可以降低请求次数和会话超时概率；同时给UploadAsync调用增加5xx错误的重试逻辑，捕获ServiceException后等待1~3秒再重试2次。
• 修正Graph客户端重试配置：将创建草稿时的重复重试配置改为统一的WithRetryOptions配置，示例如下：

Message draft = await _graphServiceClient
.Users["UserId"]
.MailFolders
.Drafts
.Messages
.Request()
.WithRetryOptions(new RetryOptions { MaxRetry = 3, RetryDelay = TimeSpan.FromSeconds(1) })
.AddAsync(message);

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