必须用嵌入式数组+复合索引方案，因固定字段会导致alterCollection频繁、$or查询爆炸、索引难对齐及语义冲突；tags需为扁平对象，含k/v/ts三字段，v仅限字符串或数字，ts建倒序索引，k与v建联合索引；批量更新须用$push或$addToSet避免覆盖；多标签查询必须用$all+$elemMatch，且字段顺序需与索引一致。
直接用固定字段存标签会迅速拖垮查询性能和维护成本，必须用嵌入式数组 + 复合索引的方案。
为什么不能用 is_active、tag_vip 这类固定字段
运营随时会新增“7天未登录”“iOS高价值试用用户”等标签，每加一个就得 alterCollection；几十个 is_* 字段会让 $or 查询爆炸，索引也难对齐；更麻烦的是语义冲突——“高净值”和“VIP_level_3”实际是同一类用户，但字段名不同，业务逻辑就容易错。
tags 数组结构怎么定义才合理
每个标签必须是扁平对象，含 k（键）、v（值）、ts（时间戳）三个字段，不嵌套、不存数组：
{ "k": "login_frequency", "v": "high", "ts": ISODate("2024-05-20T08:30:00Z") }
-
v只存字符串或数字，避免用对象或数组——MongoDB 对嵌套对象的$elemMatch查询性能差，且多层索引深度受限 -
ts单独建倒序索引：db.users.createIndex({ "tags.ts": -1 })，方便查“最近3天打的标签” -
k和v必须联合建复合索引：db.users.createIndex({ "tags.k": 1, "tags.v": 1 })，否则{ "tags.k": "device_os", "tags.v": "ios" }这种查询会全表扫描
批量更新标签时怎么避免覆盖旧数据
别用 $set: { tags: [...] }，那会清掉所有历史标签。正确做法分两种：
- 追加新标签（允许重复）：
$push: { tags: { $each: [newTag], $slice: -100 } }，$slice: -100控制最多保留100条，防数组无限膨胀 - 去重插入（要求完全一致）：
$addToSet: { tags: newTag }，但注意：带ts的标签每次时间都不同，$addToSet无法去重，得靠应用层判断是否已存在相同k/v组合
按多个标签条件筛选的写法和坑
查“既是 iOS 用户，又是 trial_expired 阶段”的用户，不能写成：
{ "tags.k": "device_os", "tags.v": "ios", "tags.k": "lifecycle_stage", "tags.v": "trial_expired" }
这实际只匹配 k 同时等于两个值，永远为 false。必须用 $elemMatch 分别约束：
{ "tags": { $all: [ { $elemMatch: { "k": "device_os", "v": "ios" } }, { $elemMatch: { "k": "lifecycle_stage", "v": "trial_expired" } } ] } }
注意：$all + $elemMatch 是唯一能表达“同时满足多个标签条件”的写法；如果只用 $and，会匹配到不同数组元素上的标签组合，结果不准。
最易被忽略的是索引覆盖问题：即使建了 tags.k 和 tags.v 的复合索引，$elemMatch 内部字段顺序也必须和索引字段顺序一致，否则索引失效。
