MongoDB中宽文档指字段多、嵌套深、信息全，适合读多写少、局部性强的场景；窄文档指字段少、扁平、靠引用关联，适合写频繁、字段变更独立或需事务强一致性的场景；实际多采用混合策略，核心依据是读写模式与访问需求匹配。
宽文档和窄文档不是 MongoDB 官方术语，而是开发者在实践中对文档结构倾向的通俗描述：前者指单个文档字段多、嵌套深、承载信息全；后者指字段少、扁平、常靠ObjectId引用其他文档。选哪种，取决于你**怎么查、怎么改、怎么扩容**，而不是“哪个更高级”。
宽文档适合：读多写少、查询局部性强、避免跨集合 JOIN
如果你的应用频繁按某个业务实体（比如用户、订单、商品）整体读取，且很少只更新其中一两个字段，宽文档能显著减少查询次数和网络往返。
- 典型场景：电商商品详情页 —— 一个
product文档包含name、price、specs（嵌套对象）、images（数组）、reviews（数组子文档），前端一次find()就能拿到全部渲染所需数据 - 注意点：
宽文档容易逼近 16MB 文档大小上限，尤其当reviews或logs类数组无节制增长时；更新整个文档比只改几个字段更重，可能引发写锁竞争（尤其 WiredTiger 引擎下影响较小，但非零） - 性能提示：对嵌套字段（如
specs.cpu）建索引需用点号路径，db.products.createIndex({"specs.cpu": 1})；数组内嵌套字段索引会生成多条索引项，要留意索引膨胀
窄文档适合：写频繁、字段变更独立、需强一致性事务或跨业务复用
当某个字段（比如用户地址、订单状态历史）更新频率远高于其他字段，或需要被多个集合共用、参与分布式事务时，拆成窄文档更可控。
- 典型场景：用户收货地址管理 ——
users集合只存name、email等核心字段，addresses集合单独存地址，用user_id引用；这样改地址不影响用户主文档，也方便做地址校验、复用到订单中 - 注意点：MongoDB 不支持跨集合
$lookup以外的真正 JOIN，$lookup是左连接、内存受限（默认 100MB）、无法索引优化；频繁$lookup+ 多阶段聚合易拖慢查询 - 事务限制：4.0+ 支持多文档事务，但仅限副本集内、单次事务最多操作 1000 个文档，且不能跨分片；若业务强依赖“用户+地址+订单”原子性更新，
窄文档反而增加事务复杂度
混合策略才是常见解法，别硬套二分法
现实中几乎没有纯宽或纯窄的设计，关键在“哪部分嵌入、哪部分引用”。
- 嵌入
静态/低频变数据：如用户性别、注册渠道、商品 SKU 基础属性 —— 这些字段几乎不改，嵌入省查询 - 引用
动态/高频变数据：如用户登录日志、订单支付流水、评论点赞数 —— 单独集合，避免主文档膨胀和更新抖动 - 警惕“伪宽文档”：把所有关联数据都塞进一个文档，却从不整体读取，只查
name和status—— 这浪费存储、拖慢索引、增加传输开销
read pattern和write pattern是否匹配文档结构。改一次字段结构成本很低，但改错一次访问模式，后续加缓存、加聚合、加冗余字段的补救成本高得多。 
