使用EWS Java发送Office365邮件遇ERROR_IRRESOLVABLE_CONFLICT错误求助

这个错误我之前帮团队排查过好几次，本质就是你操作邮件item时，手里的ChangeKey和Exchange服务器上当前item的ChangeKey不匹配——简单说就是你的本地item版本已经过期了，服务器上的item已经被隐性操作（比如EWS内部同步、代码里的重复操作）修改过了。下面是几个经过验证的可行方案：

1. 确保操作链使用最新的ItemId/ChangeKey #

当你创建邮件、添加附件、发送这一系列操作时，绝对不要一直拿着最初创建邮件时的ItemId用到底。每次修改（比如添加附件）后，必须获取服务器返回的最新ItemId和ChangeKey来继续后续操作。

给你一段Java代码示例，照着改就行：

// 1. 创建邮件并保存到草稿箱，拿到初始ItemId
EmailMessage email = new EmailMessage(service);
email.setSubject("Test Subject");
email.setBody(MessageBody.getMessageBodyFromText("Test Body"));
email.getToRecipients().add("recipient@example.com");
email.save(WellKnownFolderName.Drafts);
ItemId draftItemId = email.getId();

// 2. 添加附件：必须重新绑定最新的邮件实例，修改后再更新
EmailMessage emailWithAttachment = EmailMessage.bind(service, draftItemId);
FileAttachment attachment = emailWithAttachment.getAttachments().addFileAttachment("C:\\test.pdf");
attachment.setName("Test.pdf");
// 这里一定要指定冲突解决模式，同时拿到更新后的ItemId
emailWithAttachment.update(ConflictResolutionMode.AlwaysOverwrite);
ItemId updatedItemId = emailWithAttachment.getId();

// 3. 发送邮件：用更新后的ItemId绑定最新实例
EmailMessage finalEmail = EmailMessage.bind(service, updatedItemId);
finalEmail.send();

核心逻辑就是：每次修改后要么重新bind获取最新item，要么用update返回的结果，保证后续操作的ChangeKey是服务器认可的最新版本。

2. 显式指定ConflictResolutionMode处理冲突 #

默认情况下，EWS的update或send方法会在ChangeKey不匹配时抛出异常（也就是你现在遇到的错误）。你可以显式指定冲突解决模式，告诉服务器怎么处理这种情况：

• ConflictResolutionMode.AlwaysOverwrite：直接用你的本地版本覆盖服务器上的版本（适合你确定当前操作是最终状态的场景）
• ConflictResolutionMode.AutoResolve：让服务器自动合并可兼容的冲突（比如不同字段的修改）
• ConflictResolutionMode.NeverOverwrite：默认行为，冲突就抛异常

比如添加附件后更新时：

emailWithAttachment.update(ConflictResolutionMode.AlwaysOverwrite);

或者发送邮件时直接指定：

finalEmail.send(MessageDisposition.SendOnly, ConflictResolutionMode.AlwaysOverwrite);

3. 排查隐性的并发操作 #

有时候冲突是因为其他进程在偷偷修改同一个邮件item——比如你的代码里有没有异步线程同时处理草稿箱？或者本地Outlook、其他EWS客户端在同步草稿箱？

给你几个排查方向：

• 确保单个邮件的创建、修改、发送流程是单线程执行的，不要并行操作同一个item
• 如果是批量发送邮件，每个邮件的操作要完全独立，不要共享ItemId
• 暂时关闭本地Outlook或其他同步工具，测试是否还会出现冲突，排查是不是外部同步导致的ChangeKey变化

4. 别再依赖延迟了，没用的 #

你之前加1秒延迟的思路其实是碰运气，赌服务器能在1秒内完成同步，但Exchange/365的负载是动态的，有时候1秒不够，有时候又浪费时间。真正靠谱的是通过获取最新的ItemId/ChangeKey来替代延迟，这才是从根源解决问题的方式。

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