结论：应选用@fastify/mongodb插件配合集群模式，避免使用mongoose；吞吐瓶颈主因是单进程阻塞与连接复用不足，而非数据库连接本身。
直接结论：用 @fastify/mongodb 插件 + 集群模式，别碰 mongoose；吞吐量瓶颈不在数据库连接本身，而在单进程阻塞和连接复用不足。
为什么不用 mongoose 而选 @fastify/mongodb
Fastify 是异步优先框架，mongoose 的中间层（如 schema 验证、中间件钩子、自动类型转换）会吃掉 async/await 的收益，且默认连接池行为与 Fastify 生命周期不协同。而 @fastify/mongodb 是轻量封装，直接暴露 this.mongo.db 和 this.mongo.client，全程走原生 mongodb 驱动的异步 API。
- 它不拦截或重写查询逻辑，
collection.find().toArray()就是原生调用 - 支持
forceClose: true，确保fastify.close()时 MongoDB 连接真正释放，避免进程残留连接泄漏 - 注册即绑定，无需手动管理 client 实例生命周期，避免在路由里重复
new MongoClient()
如何正确配置连接参数避免连接池打满
MongoDB 官方驱动默认 maxPoolSize: 100，但在 Fastify 多 worker 场景下，每个进程都开满 100 连接，8 核机器就可能瞬间占用 800 连接——远超 MongoDB 默认 maxConnections（通常 65536，但实际受 ulimit 和内存限制）。
- 显式设低：在
register选项中加maxPoolSize: 20（按并发请求峰值预估 ×1.5） - 必须配
minPoolSize: 5，防止冷启动时反复建连 - 加
connectTimeoutMS: 3000和socketTimeoutMS: 5000，避免慢查询拖垮整个 worker - URL 中不要带
replicaSet或readPreference等冗余参数，除非真用到副本集读写分离
集群模式下 MongoDB 连接怎么不重复创建
Node.js cluster 模块 fork 出多个 worker 进程，如果每个 worker 都执行 fastify.register(@fastify/mongodb)，就会各自建一套连接池——这不是“复用”，是“爆炸式增长”。
- 只在主进程（
cluster.isPrimary === false的 worker）里注册插件 - 确保
fastify.register()不在if (cluster.isPrimary)块内执行 - 更稳妥的做法：把数据库注册抽成独立函数，在 worker 启动后才调用，例如：
if (cluster.isPrimary) {
// 主进程只管 fork，不注册任何插件
} else {
const fastify = require('./app')() // app.js 里只注册路由和 @fastify/mongodb
fastify.listen({ port: 3000 })
}
用 PM2 时同理：启动命令加 -i max，但 @fastify/mongodb 必须在每个 worker 内部注册（PM2 的每个 instance 是独立进程），此时更要严格控制 maxPoolSize。
吞吐量卡在哪儿？几个常被忽略的点
很多人压测发现 QPS 上不去，第一反应是“MongoDB 慢”，其实 80% 情况下是 Fastify 层没做对：
-
reply.send()前没加await对异步查询结果 —— 导致 reply 提前结束，后续find().toArray()报错被吞掉 - 路由里用了
sync操作（比如fs.readFileSync、JSON.parse 大字符串）—— 直接阻塞整个 event loop - 没关日志级别：
logger: { level: 'info' }在高并发下大量序列化日志对象，CPU 占用飙升 - 忘了加
fastify.setValidatorCompiler()自定义校验器 —— 默认 JSON Schema 校验在每请求都编译，开销极大
真正影响吞吐的是这些“看不见”的同步操作和资源误配，不是 MongoDB 本身。先跑通单 worker + 连接池调优，再上集群，顺序错了，越压越乱。
