重复线索最难处理的不是发现两条像，而是合并之后到底哪条算“主线索”，以及原来的沟通痕迹如何不丢也不乱。
这篇文章主要参考了以下企业版源码与测试入口：
enterprise/data_merge_crm/models/crm_lead.py
一、这个模块真正解决的不是表面动作，而是跨模块语义对齐
data_merge_crm 的核心不是删掉重复 lead，而是如何选主记录、如何把 source 合并进 destination，以及哪些历史信息该迁、哪些不能乱拼。
如果只看 UI，很容易把它理解成一个按钮、一张表或一个新视图。但从 data_merge_crm 的模型、测试和桥接关系看，官方真正关心的是：前台动作发生以后，后端主链路能不能继续保持同一套业务语义。
二、核心机制链路
1. 先选主记录，再谈合并
_elect_master(records) 说明去重不是对称操作，系统必须明确 destination 是谁，否则 stage、负责人、概率等字段都没有锚点。
2. merge method 决定哪些东西向主记录回流
_merge_method(destination, source) 的存在本身就说明 CRM 去重不是通用 copy，而是对 lead 这种带业务进度对象做定制合并。
3. CRM 去重关注历史连续性
即便源码很短，模块独立存在也在提醒：线索去重不只是表数据压缩，它必须维护销售跟进链路的可解释性。
三、最容易被误解的边界
- 把去重当成删除 source，忽略 master election。
- 默认所有字段都取非空值覆盖，导致主 lead 关键状态被冲掉。
- 不考虑消息、活动、负责人等业务痕迹在合并后的连续性。
这些误解之所以常见，往往是因为大家只看见“入口动作”，却没有继续追到模型方法、状态切换、聚合口径和测试场景里去看 Odoo 究竟把什么当成事实、把什么当成辅助信息。
四、实施与排查时，建议按这个顺序看
- 先确认 master election 规则是否符合业务预期。
- 再检查 merge method 对关键字段的取舍。
- 最后抽查合并后 chatter / activities / 商机状态是否仍然连贯。
对企业版功能来说，排查顺序非常重要。很多看似是“结果不对”的问题，真正根因往往更早：字段上下文没带过去、桥接对象没建、状态机没推进、或者权限/公司边界一开始就错了。
五、结论
CRM 去重真正难的地方，是把“两个像同一条线索的记录”收束成一条还能继续跟进的销售事实。
DISCUSSION
评论区