maxpoolsize需按峰值qps×0.8÷单连接处理时间估算并上浮10%，minpoolsize≥预热期并发数且不低于10，sockettimeoutms和connecttimeoutms须小于上游lb超时，避免悬挂请求。
连接池配置直接影响吞吐量上限
连接池不是“开得越大越好”。maxPoolSize设为100在QPS超2000时确实能稳住，但若实际业务平均并发仅300，反而会拖慢连接复用效率、增加MongoDB端的上下文切换开销。实测中，minPoolSize低于10会导致冷启动延迟明显——比如服务刚重启后前几十个请求平均多耗时80ms。
-
maxPoolSize建议按峰值QPS × 0.8 ÷ 单连接平均处理时间（单位秒）粗估，再向上取整10%作为安全余量 -
minPoolSize必须 ≥ 应用预热期预期并发数，Node.js进程启动后应主动触发一次空查询（如db.command({ ping: 1 })）来“暖池” -
socketTimeoutMS和connectTimeoutMS必须小于上游Nginx或负载均衡器的超时设置，否则会出现“连接已断但请求未终止”的悬挂状态
复合索引是否生效，不能只看createIndex语句
写了db.orders.createIndex({ userId: 1, status: 1, createdAt: -1 })不等于查询就走索引。MongoDB是否真正使用它，取决于查询条件顺序、投影字段、以及是否满足覆盖索引（covered query）条件。
dmap-jsapi-skill
下载
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
- 执行
db.orders.find({ status: 'shipped', userId: '123' }).explain('executionStats')，重点看executionStages.stage是否为IXSCAN，且nReturned≈totalDocsExamined - 如果查询带了
$or或正则表达式（非前缀匹配），即使有索引也可能退化为COLLSCAN - 聚合管道中
$match必须放在$lookup之前，否则索引无法下推到被关联集合
bufferCommands: false 不是万能开关
设bufferCommands: false加bufferMaxEntries: 0确实能让数据库断连时立即报错，但前提是你的代码里没有手动缓存待写入数据。一旦业务层做了本地队列（比如攒批发消息），这个配置就失效了。
- 真正起作用的是驱动层对
insertOne/updateMany等操作的底层调用时机，而非Mongoose Schema级配置 - 如果你用了
save()方法，必须确保每个实例都显式调用await，否则Promise可能被丢弃，错误根本不会冒泡到上层 - 断连期间所有未
await的Promise会静默拒绝（rejected），日志里只显示UnhandledPromiseRejectionWarning，容易被忽略
批量写入bulkWrite的ordered参数陷阱
ordered: false看似能加速失败容忍，但实际会掩盖部分写入成功的结果。比如100条插入中第50条因唯一键冲突失败，其余99条仍会写入——而你拿到的result对象里result.upsertedCount和result.insertedCount是合并统计的，无法定位哪几条成功了。
- 调试阶段务必用
ordered: true，配合writeConcern: { w: 1 }快速暴露问题 - 生产环境启用
ordered: false时，必须检查result.writeErrors数组，并逐条比对原始bulkOps索引位置 - 避免在事务内使用
bulkWrite，MongoDB 6.0+虽支持，但ordered: false在事务中会被强制转为true，导致行为不一致
MongoClient实例必须全局复用，重复new MongoClient()哪怕只差毫秒，都会创建独立连接池，最终耗尽文件描述符。这不是配置问题，是架构层面的硬约束。
