本文介绍如何使用 MongoDB 和 Express 构建一个高性能的 /explore/albums 接口，一次性返回所有专辑数据并动态附加每张专辑包含的歌曲数量，避免常见异步陷阱与 N+1 查询问题。
本文介绍如何使用 mongodb 和 express 构建一个高性能的 `/explore/albums` 接口，一次性返回所有专辑数据并动态附加每张专辑包含的歌曲数量，避免常见异步陷阱与 n+1 查询问题。
在构建音乐类应用的后端 API 时，常需将主实体（如 Album）与其关联子实体（如 Song）的数量一并返回。但直接在 .map() 中使用 async 函数会导致返回的是 Promise 数组而非实际数据——这正是原始代码中 res.json(albums) 发送空数组的根本原因：albums.map(async () => {}) 返回的是未 await 的 Promise 对象，而非解析后的值。
✅ 正确实现：并行查询 + 结构合并
关键在于分离数据获取与数据组装逻辑：先同步获取全部专辑，再用 Promise.all() 并行执行每个专辑的歌曲计数查询，最后统一合并结果。以下是优化后的完整路由实现：
Router.route("/explore/albums")
.get(async (req, res) => {
try {
// 1. 获取所有专辑（同步查询）
const albums = await _Albums.find().lean(); // .lean() 提升性能，返回纯 JS 对象
// 2. 并行统计每张专辑的歌曲数量
const albumsWithSongs = await Promise.all(
albums.map(async (album) => {
const numberOfSongs = await _Songs.countDocuments({ album: album.name });
return { ...album, numberOfSongs }; // 直接展开，无需 toObject()（若已使用 .lean()）
})
);
res.json(albumsWithSongs);
} catch (e) {
console.error("Failed to fetch albums with song counts:", e);
res.status(500).json({ error: "Internal Server Error" });
}
});? 关键优化点说明
- countDocuments() 替代 find().length：countDocuments 是 MongoDB 官方推荐的高效计数方法，不加载文档内容，显著降低内存与网络开销。
- .lean() 提升性能：_Albums.find().lean() 返回普通 JavaScript 对象而非 Mongoose Document 实例，避免序列化开销，且可直接解构扩展。
- Promise.all() 并行执行：确保所有歌曲计数请求并发发起，而非串行等待，大幅缩短响应时间（尤其在专辑数量较多时）。
- 健壮错误处理：捕获异常并返回标准 HTTP 状态码与结构化错误响应，便于前端统一处理。
⚠️ 注意事项与进阶建议
- 字段一致性：确保 Song 文档中的 album 字段与 Album.name 严格匹配（建议统一使用 albumId ObjectId 引用，而非字符串名称，避免大小写/空格歧义）。
-
索引优化：为 Songs.album 字段建立数据库索引，加速 countDocuments 查询：
_Songs.createIndex({ album: 1 }); - 分页与缓存：生产环境应添加分页（如 limit/skip）及 Redis 缓存，防止高频请求反复触发聚合计算。
- 替代方案（聚合管道）：若数据模型支持 ObjectId 关联（如 Song.album 指向 Album._id），更推荐使用 MongoDB 聚合（$lookup + $count），单次查询完成全部逻辑，性能更优。
通过以上实现，你将获得一个语义清晰、性能可靠、易于维护的专辑+歌曲数接口，为前端音乐探索页提供坚实的数据支撑。
