适合的场景，通常都有一个共同点：
业务对象本身就像一份完整档案。
很适合
- 用户资料、配置、偏好设置
- 商品目录、内容管理、知识条目
- 订单、工单、消息、事件流
- 结构会演进的业务对象
- 需要快速迭代的数据模型
- 读某个对象时，希望一次拿全大部分信息
不那么适合，或者要非常谨慎
- 高度依赖复杂多表连接的系统
- 强一致跨多记录联动极多的场景
- 关系网络非常复杂且频繁跨实体联查
- 报表主要建立在大量高度规范化联结之上
- 会把超大、无限增长的子集合长期塞进单文档的场景
这不是说 MongoDB 做不到某些事，而是说：
能做 ≠ 做起来最自然数据库选型的关键不是“功能表谁更多”，而是：
- 你的业务长得像什么
- 你的读写路径长什么样
- 你的团队是否能驾驭对应的建模方式