先说结论
一个邮箱插件要好用，关键不只是能不能创建联系人，而是它能不能在“联系人、公司、富化资料、权限边界”之间做出像样判断。Mail Plugin 在这方面其实相当克制。
第一层：为什么先找公司，而不是先盲建联系人
res_partner_get() 在查不到联系人时，不会立刻催你新建，而是先尝试 _find_existing_company()。这说明官方认为：插件场景里，联系人往往只是一个入口，更重要的是能不能把他挂回正确公司。如果先乱建联系人，后面数据很容易碎成孤岛。
第二层：域名缓存为什么比实时富化更重要
_find_existing_company() 会先看 res.partner.iap 缓存，再找现有公司，而不是每次都直接打 IAP。因为真正昂贵的不是“搜公司”这个动作，而是外部富化调用的成本和不确定性。缓存优先，说明系统在把插件体验和外部依赖成本一起考虑。
第三层：什么情况下才会新建并富化公司
当数据库里没有现成公司、当前用户又有创建权限时，系统才会 _create_company_from_iap()。它会把公司名、地址、电话、网站、国家州信息甚至 logo 一起带回来，再把原始富化信息写到 iap_enrich_info。这说明官方并不把富化当成“补个 logo”，而是把它视作主数据初始化过程的一部分。
第四层：为什么无权限时也要返回最小信息
_get_company_data() 在没有读取权限时不会直接报错，而是返回 {id, name: No Access}。这很有产品感：插件端至少需要知道“这个公司存在但你看不到细节”，否则用户会误以为系统里压根没有对应记录。
第五层：通知邮箱为什么被特殊处理
源码会把 notification address 单独拦出来，不允许直接当联系人绑定。这其实是在避免“系统回执邮箱”“别名邮箱”混入真实业务联系人。很多集成失败并不是接口报错，而是数据边界没分清。Mail Plugin 在这里专门踩了刹车。
最容易误解的三个点
- 误区一：联系人查不到就应该立刻新建。对邮件场景来说，先找公司归属往往更重要。
- 误区二：IAP 富化越频繁越智能。实际里缓存优先往往更稳、更省。
- 误区三：权限不足就直接报错最安全。插件体验上，适度返回“存在但不可读”更有帮助。
实战上怎么用更稳
- 做类似邮箱集成时，先想清楚公司复用规则，再谈联系人创建规则。
- 富化服务最好有缓存层，否则插件首次体验会抖得很厉害。
- 如果用户说“为什么插件搜不到”，检查通知邮箱和访问权限边界。
最后总结
Mail Plugin 之所以像样，不是因为它会“自动建联系人”，而是因为它在自动化之前，先认真处理了公司归属、缓存、权限和异常邮箱这几条边界。
DISCUSSION
评论区