我来给你拆解这个问题——这种情况其实是Outlook 2013/2016的资源保护机制在起作用，并非O365加载项本身存在兼容性问题，更不是“安装大型COM加载项就一定会导致O365加载项失效”。

为什么会出现这个现象？ #

Outlook 2013/2016对COM加载项的资源占用有隐性阈值限制，当你安装的大型COM加载项触发以下任意一种情况时，就会触发保护机制：

• UI线程资源被抢占：如果COM加载项注册了大量高频触发的Outlook对象模型事件（比如ItemSend、ExplorerSelectionChange），或者长时间占用UI线程执行任务，Outlook为了避免新建邮件界面卡顿甚至崩溃，会默认禁用O365（Web加载项）的加载。
• 内存占用超标：大型COM加载项如果存在内存泄漏或本身体积过大，会导致Outlook进程的可用内存低于加载Web加载项的最低要求，新建撰写界面时就会跳过Web加载项的初始化流程；而草稿邮件属于已加载的会话，内存状态相对稳定，所以还能正常访问O365加载项。

可行的解决方案 #

• 优化COM加载项的资源占用
  如果是你自主开发的COM加载项，建议：
  • 减少不必要的全局事件钩子，改用按需触发的逻辑（比如只在特定场景下注册事件）；
  • 严格遵循Outlook对象模型的最佳实践，显式释放所有对象引用（尤其是VBA/COM开发中，避免内存泄漏）。
• 调整加载项的启用状态与优先级
  1. 打开Outlook，进入文件 > 选项 > 加载项；
  2. 在底部“管理”下拉框选择“COM加载项”，点击“转到”；
  3. 禁用非必要的大型COM加载项，只保留核心功能的；部分版本支持通过注册表修改加载优先级（操作前请备份注册表）。
• 修改注册表放宽Web加载项限制（进阶操作）
  针对Outlook 2013/2016，可通过注册表调整保护机制阈值：
  1. 打开注册表编辑器regedit；
  2. 定位到对应版本的路径：
     • Outlook 2013：HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Outlook\Addins
     • Outlook 2016：HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Addins
  3. 新建DWORD值DisableWebAddinBlocking，设置值为1；
  4. 重启Outlook生效。

  注意：修改注册表存在系统风险，操作前务必备份注册表。

• 升级Outlook版本
  如果条件允许，升级到Outlook 2019或Microsoft 365订阅版，这些版本对加载项的资源管理机制更完善，大幅降低了这类资源冲突触发的概率。

补充说明 #

安装大型COM加载项并非一定会导致O365加载项无法运行，只要两者的资源占用总和在Outlook的阈值范围内，完全可以共存。你遇到的是资源冲突触发保护机制的极端场景，核心解决思路是降低资源占用或调整限制规则。

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