MongoDB不支持原生位图，应用层模拟存在索引失效、非原子更新、语义模糊等问题；字符串数组虽简单但难区分同名标签、无法记录时间；推荐使用带k/v/ts字段的嵌入对象数组，配合复合索引和原子操作实现高效、可维护的标签系统。
位图在MongoDB中根本不可用
MongoDB 没有原生位图（Bitmap）数据类型，也不支持按 bit 位读写字段。你无法像 Redis 那样用 SETBIT 或 GETBIT 操作一个字段的某一位。所有所谓“MongoDB 位图”方案，本质是应用层模拟——比如把整数转成二进制字符串再存进 String 字段，或用 Int32/Int64 字段做位运算。但这类做法：
- 查询时无法利用索引（bitwise 运算不走索引）
- 更新需先读、再算、再写，非原子，高并发下极易出错
- 无法表达标签语义（比如你存了 0b101，谁知道第 2 位代表“iOS”还是“高价值”？）
- 一旦位数超限（如用户标签超过 64 个），就得切分字段或升级类型，维护成本陡增
字符串数组不是最优解，但比位图现实得多
直接用 tags: ["ios", "high_value", "trial_expired"] 这种纯字符串数组看似简单，实际很快会暴露问题：
- 无法区分同名不同义的标签（比如两个业务线都用了 "vip"，但含义完全不同）
- 无法记录打标时间，导致“最近3天活跃用户”这类查询必须额外加字段或查日志
- 无法支持多值同 key（比如一个用户有多个 interest 标签："ai" 和 "devops"），$in 会误匹配
- tags 字段建索引后，MongoDB 会为每个数组元素生成一条索引条目，100 个标签 = 100 条索引记录，写放大严重
真正该用的是带 key/value/ts 的嵌入对象数组
这是 MongoDB 用户标签系统的事实标准结构，原因很实际：
- k 字段统一语义（避免 "vip" 和 "is_vip" 混用）
- v 字段保留值的可读性与可枚举性（不用硬编码数字映射）
- ts 字段支撑时效性查询与 TTL 清理
- 复合索引 {"tags.k": 1, "tags.v": 1} 能让 { "tags.k": "device_os", "tags.v": "ios" } 查询走索引，毫秒级返回
- 更新可用 $addToSet（去重新增）、$pull（批量删某类）、$push + $each + $slice（保序截断），避免覆盖历史
容易被忽略的细节：索引和更新的耦合陷阱
很多人建了 {"tags.k": 1, "tags.v": 1} 就以为万事大吉，但实际踩坑点很具体：
- 如果查询只用 "tags.k": "interest"，没带 v，这个复合索引无法跳过 v 字段做范围扫描，可能退化为全索引扫描
- $addToSet 对对象去重要求**所有字段完全一致**，所以带 ts 的标签不能靠它去重，否则每次都是新条目
- 数组长度超过 50～100 项后，写入延迟和索引体积增长非线性上升，必须配合定时 job 清理过期标签（例如 tags.ts 超过 90 天的）
- 不要试图在 v 里存 JSON 字符串或嵌套对象，MongoDB 对数组内子文档的索引深度有限制，且 $elemMatch 性能随嵌套层级下降明显
