Outlook add-in开发：如何通过REST API移除加载项或监听移除事件

一、捕获用户移除外接程序的事件 #

首先明确运行时限制：Outlook Web Add-in运行在沙箱隔离环境中，用户手动卸载add-in时，Outlook会直接销毁add-in的运行时进程，不会向add-in内部下发任何卸载事件，你在add-in代码里注册的beforeunload、Office.onReady销毁回调这类逻辑都不会被触发，没有前端侧直接捕获卸载事件的方案。
可行的落地方案有两个：

• 心跳判定法（成本最低，最常用）：add-in每次启动、以及运行期间按固定间隔（比如24小时一次）向你的自有服务端上报心跳，带上当前用户标识、add-in版本信息。你在服务端设置超时阈值，比如连续7天没有收到某用户的心跳，就可以判定该用户已经卸载add-in，触发你自己的后续业务逻辑。
• Graph变更通知法（实时性更高）：在你的服务端对接Microsoft Graph变更通知能力，申请Apps.Read.All委托/应用权限，订阅指定用户的已安装应用变更通知。当用户卸载你注册的add-in时，Graph会向你提前配置的公网通知端点推送变更事件，你可以实时拿到卸载行为。注意这个方案需要你的服务端暴露可公网访问的HTTPS接口，且要完成Graph通知的URL校验逻辑。
  如果你的add-in是通过微软AppSource分发，你只能在合作伙伴中心拿到聚合的卸载统计数据，拿不到单个用户的卸载明细和实时事件。

二、通过REST API移除外接程序 #

所有移除操作都通过Microsoft Graph API实现，根据add-in的部署类型选择对应接口：

场景1：移除用户个人自行安装的add-in #

1. 提前在Azure AD注册应用，申请MailboxSettings.ReadWrite委托权限或者User.ReadWrite.All应用权限（应用权限需要租户管理员同意）
2. 获取对应用户的有效访问令牌
3. 调用删除接口，路径里的{extensionId}替换为你add-in manifest文件里声明的唯一Id：

DELETE https://graph.microsoft.com/v1.0/users/{user-id}/extensions/{extensionId}
Authorization: Bearer {access_token}

接口返回204 No Content状态码即代表移除成功，用户重启Outlook后就看不到该add-in。
如果是当前登录用户移除自己安装的add-in，可以把路径里的/users/{user-id}替换为/me简化调用。

场景2：移除租户内管理员统一部署的add-in #

1. 使用租户管理员账号授权，给Azure AD应用分配AppCatalog.ReadWrite.All应用权限
2. 先查询对应add-in在租户应用目录中的部署ID、定义ID
3. 调用统一应用目录的删除接口：

DELETE https://graph.microsoft.com/v1.0/appCatalogs/teamsApps/{app-id}/appDefinitions/{app-definition-id}
Authorization: Bearer {access_token}

接口调用成功后，该add-in会自动从所有授权用户的Outlook、Teams等M365客户端中移除，不需要用户手动操作。

注意：不要在add-in前端代码中硬编码Azure AD应用的密钥信息，所有Graph API调用建议放到你的自有服务端做转发，避免密钥泄露。

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