VSTO Outlook如何处理撰写窗口To/CC/BCC栏收件人悬停事件

Outlook官方VSTO对象模型没有直接暴露邮件撰写窗口内「收件人(To)」「抄送(CC)」「密送(BCC)」字段单个收件人条目的鼠标悬停事件，但是可以通过以下两种成熟方案实现需求，不存在技术层面的不可行障碍。

方案1：Windows API钩子 + 控件命中测试（推荐，兼容性最好） #

这是目前商用Outlook插件最常用的实现方式，适配Outlook 2013到最新的365版本，侵入性极低：

• 首先监听Outlook的Inspectors.NewInspector事件，拿到新打开的邮件撰写窗口的句柄，定位窗口内承载收件人输入的控件（新版本Outlook为NetUI类控件，旧版本为收件人专用RichEdit控件）
• 给当前撰写窗口的UI线程注册WH_MOUSE类型的线程级鼠标钩子，监听鼠标悬停消息，当检测到鼠标停留在收件人控件客户区时，触发命中判定逻辑
• 调用Windows标准IAccessible无障碍接口遍历收件人控件的子元素，匹配鼠标当前坐标对应的子元素，就能拿到悬停目标对应的单个收件人姓名、邮箱地址、条目类型（收件人/抄送/密送）信息，之后即可执行自定义的业务处理逻辑
• 注意要在撰写窗口关闭时及时卸载挂载的钩子，避免内存泄漏；不同大版本Outlook的控件类名、无障碍接口层级有差异，需要做少量版本适配逻辑，不要直接调用Outlook未公开的内部COM接口，否则版本更新后极易导致Outlook崩溃。

方案2：自定义控件替换原生收件人区域（实现逻辑简单，侵入性高） #

如果不想做复杂的API钩子适配，可以选择直接替换原生UI：

• 检测到邮件撰写窗口打开后，隐藏原生的收件人、抄送、密送输入区域，在原位置注入自定义开发的WPF/WinForm收件人输入控件
• 自定义控件可以完全自主实现所有交互逻辑，单个收件人条目的悬停、点击、右键菜单等事件都可以直接响应，不需要额外做系统级监听
• 该方案的缺点是需要1:1复现原生收件人控件的所有能力，包括地址簿调用、收件人自动补全、无效地址标记、拖拽排序等，开发量较大，且容易和其他修改撰写窗口UI的插件产生冲突。

原生收件人字段界面效果参考：

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