应优先使用字符串数组 tags: ["mongodb", "nosql", "performance"]；仅当需高频查询标签元数据（如权重、时间）时才用嵌套文档；绝大多数场景无需单独建 tags 集合；热门标签统计应通过定时聚合写入缓存集合，避免实时更新；复合索引须按查询条件前缀顺序构建并用 explain 验证。
标签字段该用数组还是嵌套文档？
直接用 tags: ["mongodb", "nosql", "performance"] 数组最常见，也最合理。MongoDB 对数组字段的索引和查询支持成熟，$in、$all、$elemMatch 都能高效工作。嵌套文档（比如 {name: "mongodb", weight: 12}）只在需要为每个标签附加元数据（如出现频次、权重、创建时间）且这些字段参与高频查询时才值得引入——否则纯属增加写入开销和文档体积。
常见错误是过早设计“可扩展结构”：先定义 tags: [{name: "x", count: 1}]，结果后续发现 count 从不被查询，反而每次更新都要 $inc + $push，逻辑变重、容易出错。
- 如果只需“查带某几个标签的文章”，用字符串数组 + 复合索引即可
- 如果需“按标签热度排序前10”，才考虑把
count拆到独立集合或用聚合实时计算 - 避免深度嵌套：
tags: [{name: "x", meta: {source: "user", at: ISODate(...)}}]会让索引膨胀、更新变慢
要不要把标签单独建集合？
绝大多数博客场景不需要。单独建 tags 集合 + 在文章里存 tagIds: [ObjectId(...)] 引用，只在两种情况下必要：
- 标签本身有复杂属性（如描述、分类、审核状态），且这些属性被独立查询或管理
- 单个标签要关联成千上万篇文章，导致文章文档因嵌入标签列表而逼近 16MB 上限（实际中极少发生）
反例：为“支持标签编辑”就拆集合——这本质是业务逻辑问题，不是数据模型问题。可以在更新文章时同步维护一个轻量级 tags_summary 集合，而非强耦合主文档结构。
性能影响很实在：一次 find({tags: {$in: ["mongodb"]}}) 是单次索引扫描；换成 $lookup 关联标签集合，即使加了索引，I/O 和内存开销也翻倍，聚合阶段还可能触发临时磁盘排序。
如何支撑“热门标签”统计又不拖慢写入？
别在写文章时实时更新全局标签计数器。写操作必须快，而统计是读密集型任务。正确做法是分离关注点：
- 写入时只保证文章文档含准确
tags数组，不做任何跨文档更新 - 统计用后台聚合作业（如每天凌晨跑一次）：
db.posts.aggregate([{$unwind: "$tags"}, {$group: {_id: "$tags", count: {$sum: 1}}}, {$sort: {count: -1}}, {$limit: 50}]) - 结果写入缓存集合
top_tags，应用层直读，TTL 设 24 小时
有人试图用 $addToSet + 单独计数器文档实现“近实时”，但会引发写冲突（多个文章同时添加同一标签）、难以原子更新、且对高并发写入不友好。真实流量下，延迟几小时的统计完全可接受，而稳定性不可妥协。
复合索引怎么建才真正生效？
只建 {tags: 1} 索引不够。当查询同时带其他条件（如状态、时间范围）时，必须用复合索引覆盖全查询路径。例如：
- 查“已发布、2026年内、带 mongodb 标签”的文章 → 索引应为
{status: 1, publish_date: -1, tags: 1} - 查“草稿中、按标签数量降序”的文章 → 索引
{status: 1, "tags.0": 1}无效，得用$expr+ 聚合，此时更应提前算好tag_count字段并索引它
关键陷阱：tags 在复合索引中位置不能太靠后。如果索引是 {author_id: 1, tags: 1, status: 1}，而查询只用了 {author_id: ObjectId(...), status: "published"}，那 tags 部分完全无法利用——B树索引要求前缀匹配。
验证方法永远是 db.posts.find(...).explain("executionStats")，盯住 nReturned 和 totalDocsExamined 是否接近，而不是只看有没有 indexName。
