不能直接用嵌套文档建客户主表，因会导致查询变慢（$unwind开销大）、更新冲突（多人改同一文档触发写锁）、历史快照难保留（嵌套字段更新即覆盖），违背MongoDB“读写权衡”设计本质。
为什么不能直接用嵌套文档建客户主表
很多团队一开始会把客户所有信息（订单、投诉、标签、行为日志）全塞进一个 customers 集合的嵌套数组里，结果很快遇到三个硬伤：查询变慢（$unwind 开销大）、更新冲突（多人同时改同一文档的不同子项触发写锁）、历史快照难保留（比如某次营销活动打的标签需要留痕，但嵌套字段一更新就覆盖了）。MongoDB 的文档模型不是“越嵌套越方便”，而是“在读写权衡点上做取舍”。
用视图 + 分离集合支撑动态客户视图
真正的动态视图能力来自结构分离和运行时聚合，不是靠单表堆字段。核心是这三类集合：
-
customers：只存强一致性主干字段（_id、email、phone、created_at），加唯一索引 -
customer_events：流式记录所有触点（访问网页、提交表单、客服通话），带type和timestamp，按customer_id+timestamp复合索引 -
customer_tags：存标签快照，每条含customer_id、tag_name、source（如 “CRM规则引擎_v2”）、valid_from、valid_until
然后用 db.createView() 构建视图，比如实时客户画像视图：
db.createView("customer_360", "customers", [
{ $lookup: {
from: "customer_events",
localField: "_id",
foreignField: "customer_id",
as: "recent_events",
pipeline: [{ $sort: { timestamp: -1 } }, { $limit: 5 }]
}
},
{ $lookup: {
from: "customer_tags",
localField: "_id",
foreignField: "customer_id",
as: "active_tags",
pipeline: [{ $match: { valid_until: { $gte: "$$NOW" } } }]
}
}
])
注意：$$NOW 是 MongoDB 5.0+ 支持的变量，避免硬编码时间；$lookup 的 pipeline 参数必须显式写出，否则无法过滤关联数据。
视图性能陷阱与绕过方案
视图每次查询都重跑聚合管道，如果 customer_events 有千万级文档，$lookup 就成瓶颈。别指望加索引能救——索引只加速 from 集合的扫描，不加速关联逻辑本身。
- 高频查询场景（如客服系统实时调客户页）：用定时任务把视图结果物化到
customer_360_cache集合，每5分钟刷新一次，查缓存而非视图 - 需要精确到秒的实时性（如风控拦截）：放弃视图，直接用应用层拼查，先
db.customers.findOne()，再并发查customer_events和customer_tags，靠连接池和超时控制兜底 - 权限隔离需求：创建脱敏视图（如
customer_public_view），在$project阶段显式排除id_card、address字段，再给前端服务账号只授该视图权限
标签系统必须支持版本与来源追溯
CRM 中“高价值客户”这类标签不能是布尔开关，否则你永远说不清：这个标签是谁、什么时候、基于什么规则打上的。否则审计出问题或模型回滚时无从排查。
关键设计点：
- 每个
customer_tags文档必须带source_version（如 “rfm_model_v3.2”），而不是只存source - 避免用
$set更新标签，一律用新文档插入 + 设置valid_until终止旧记录，形成时间线 - 在视图里聚合标签时，用
$group+$last拿最新有效标签，而不是$max，因为valid_until可能为空（表示永久有效）
真正难的从来不是建出能跑的模型，而是让每次标签变更可追溯、可回滚、可对齐业务口径——这点在 MongoDB 里靠文档结构约束比靠代码逻辑更可靠。
