Outlook 2016外接程序中MailItem的AttachmentRemove事件未触发

• 这部分不是你的订阅逻辑或者GC回收问题，核心是Outlook 2016特定版本本身的两个已知缺陷，刚好命中了你代码里的事件触发链路：
  1. 早期2016 RTM版本（你提到的16.0.5113.1000版本）、2102通道13801版本存在COM事件接口绑定错位bug：同个MailItem对象上，AttachmentAdd事件走标准的ItemEvents_10事件派发管线，而AttachmentRemove事件的连接点被错误绑定到了旧版的ItemEvents旧接口上，用标准实例委托挂接的方式根本接不到这个事件的回调。
  2. 上述版本还存在阅读态操作的事件管线割裂问题：如果用户是在邮件的只读阅读窗格下删除附件，Outlook会直接修改存储层的附件集合，不会触发前端编辑器管线里的AttachmentRemove事件，只有在新建/编辑邮件的状态下删附件才会抛事件。这也是为什么你在2013版本里测试全部正常，升级到2016后就出现单事件失效的问题。
• 你提到的代码里直接给MailItem实例挂事件的写法，本身是没问题的，但刚好卡在了2016版本的bug触发条件上。

• 第一优先做版本基线修正：把测试环境和最终分发的Outlook 2016客户端升级到16.0.14326.20438及以上的稳定版本。上述提到的事件绑定错位、阅读态不抛AttachmentRemove的bug，微软都在后续的累计更新里做了修复。
• 做兼容兜底逻辑，避免受后续版本更新bug影响：
  1. 先在CommonItemInternal初始化的时候，缓存当前MailItem的附件总数、每个附件的名称、大小哈希列表
  2. 保留现有AttachmentAdd、AttachmentRemove的事件订阅逻辑，同时额外订阅稳定触发的PropertyChange和Item_AfterWrite事件
  3. 在AfterWrite回调里，重新拉取当前MailItem的附件集合，和之前缓存的列表做对比：如果附件总数比缓存值少，就手动调用你之前写的COM_mailItem_AttachmentRemove处理逻辑，传入被删掉的附件对象（可以通过缓存列表和当前列表的差异拿到）
• 测试场景补全：除了在新建邮件的编辑窗格测试事件触发，一定要覆盖“在已收到的已读邮件的阅读窗格下删除附件”的场景，部分旧版本客户端即使代码逻辑正确，这个场景下原生事件也不会抛出，必须靠上面提到的缓存对比兜底逻辑补全。

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