不能直接在GridFS metadata中存GeoJSON并用$near查询，因GridFS不支持地理空间索引，metadata字段需显式创建2dsphere索引且$geoNear不兼容files集合，正确做法是分离存储：用独立集合存坐标与fileId关联并建索引。
不能直接在 GridFS 的 metadata 字段里存 GeoJSON 并指望它能被 $near 或 $geoWithin 查询到 —— GridFS 本身不支持地理空间索引，metadata 是普通 BSON 对象，MongoDB 不会对其中的字段自动建立 2dsphere 索引。
为什么 metadata 中的 coordinates 查不了距离
GridFS 本质是把大文件拆成 chunks 集合 + 元信息存在 files 集合。虽然你能在 files 文档的 metadata 里写入 { location: { type: "Point", coordinates: [116.3974, 39.9093] } }，但除非你显式对 files.metadata.location 创建 2dsphere 索引，否则任何地理空间操作都会报错或静默忽略。
更关键的是：$near、$geoNear 等操作符**只作用于集合级索引字段**，不识别嵌套路径是否“看起来像 GeoJSON”。没索引 = 没球面计算能力。
- 错误现象：
error: { "ok": 0, "errmsg": "geoNear requires a 2dsphere index" } - 即使手动加了索引，
$geoNear也**不支持 GridFS 的files集合**（官方明确不保证兼容性，驱动层常抛出 unsupported operation） -
metadata字段无 schema 约束，坐标顺序写反（纬度在前）、越界（如经度=200）也不会被校验，查出来全是空结果
真正可行的替代方案：用普通集合存坐标 + fileId 关联
把地理位置当作结构化业务数据来处理，而不是塞进文件元数据。核心思路是「分离存储，关联查询」：
- 用标准集合（如
locations）存 GeoJSON 坐标和fileId，字段结构示例：{ "_id": ObjectId("..."), "fileId": ObjectId("..."), "location": { "type": "Point", "coordinates": [116.3974, 39.9093] }, "name": "北京天安门" } - 对该集合的
location字段建2dsphere索引：db.locations.createIndex({ "location": "2dsphere" }) - 查附近文件时，先查
locations集合：db.locations.find({ location: { $near: { $geometry: { type: "Point", coordinates: [116.3974, 39.9093] }, $maxDistance: 1000 } } }) - 拿到结果里的
fileId，再用GridFSBucket.openDownloadStream(fileId)拉取原始文件
如果硬要塞进 metadata，必须满足三个条件
极少数遗留系统受限于架构无法改表结构，那至少确保：
- 坐标字段路径必须可索引：例如
metadata.geo，不能是metadata.tags.0.geo这类带数组下标的动态路径 - 显式创建索引：
db.fs.files.createIndex({ "metadata.geo": "2dsphere" })（注意集合名是fs.files，不是files） - 严格校验输入：
coordinates必须是[longitude, latitude]顺序，且经度 ∈ [-180, 180]、纬度 ∈ [-90, 90]；否则索引会建成功但查询永远不命中
即便如此，$geoNear 依然大概率失败 —— 官方文档已注明 geoNear 不适用于 GridFS 的 files 集合，只能退回到 $near + find()，且无法高效分页（skip() 会全表扫）。
最易被忽略的点：很多人以为只要 metadata 里有 { type: "Point", coordinates: [...] } 就算“支持地理查询”，其实 MongoDB 完全不解析 metadata 内容语义 —— 它只认索引定义的字段路径和类型。没索引，就是纯 JSON 字符串。
