在使用MongoDB存储地理位置数据时，2dsphere索引是最常用的方案之一，它支持点、线、面等GeoJSON对象的存储和空间查询。但不少开发者遇到过这样一个报错：写入或建索引时抛出错误，故障码2300，提示类似Can't extract geo keys的错误信息。这个错误往往与坐标精度、坐标格式或几何对象的合法性有关。本文将深入分析故障码2300的产生原因，并给出系统性的排查与解决方案。
故障码2300的底层原因分析
故障码2300在MongoDB中属于地理空间键提取失败类错误。当MongoDB尝试为一个文档构建2dsphere索引键时，会调用内部的空间索引模块对GeoJSON字段进行解析和编码。这个编码过程对数据有严格要求：坐标必须是数值类型，经纬度必须落在合法范围内，几何对象必须符合GeoJSON规范。任何一项不满足，键提取就会中断并返回2300错误码。
所谓精度损失，通常出现在两类场景。第一类是坐标数值本身超出了双精度浮点数的有效表示能力，例如极小的小数位在多次计算后被截断，导致边界判断失败。第二类是坐标被存储成了字符串类型，比如"116.404"而不是116.404，此时MongoDB无法将其识别为数值，同样触发键提取失败。虽然第二类严格来说是类型错误而非精度问题，但两者在报错表现上完全一致，排查时需要一并考虑。
还有一个容易被忽视的原因是经纬度顺序。GeoJSON规范要求坐标格式为[经度, 纬度]，即longitude在前、latitude在后。这与很多地图API（如国内常见的返回格式）相反，如果开发者把纬度写在了前面，例如北京被写成[39.904, 116.404]，虽然数值都在合法范围内不会直接报错，但查询结果会完全错乱；而一旦纬度超过90，就会立即触发故障码2300。
常见触发场景与错误示例
下面通过几个典型的错误数据来说明触发条件。假设我们有一个stores集合，location字段存储GeoJSON点对象，并建立了2dsphere索引。
// 正确的写入方式：坐标为数值类型，顺序为[经度, 纬度]
db.stores.insertOne({
name: "北京门店",
location: {
type: "Point",
coordinates: [116.404, 39.915] // 经度在前，纬度在后
}
});
// 错误一：坐标是字符串，触发故障码2300
db.stores.insertOne({
name: "错误示例1",
location: {
type: "Point",
coordinates: ["116.404", "39.915"] // 字符串类型无法提取地理键
}
});
// 错误二：纬度写在前面且超过90，触发故障码2300
db.stores.insertOne({
name: "错误示例2",
location: {
type: "Point",
coordinates: [120.5, 116.404] // 第二个值是经度，超过了纬度上限90
}
});
除了点对象，多边形（Polygon）也是故障码2300的高发区。GeoJSON规定多边形的外环必须闭合，即首尾坐标完全相同，且环不能自相交。如果数据来源是第三方测绘接口，多边形顶点顺序混乱导致边线交叉，MongoDB在构建索引键时就会校验失败。此外，Polygon还要求提供coordinates数组时外层再包一层中括号表示环的集合，少写一层括号同样是常见错误。
浮点精度问题则多见于计算生成的几何数据。例如通过两条线段的交点计算得到顶点，结果出现类似1.0000000000000002这样的微小越界值，或者多边形本应闭合但因为精度误差首尾坐标相差0.0000000001，某些版本会将其判定为非闭合环。这种情况下报错信息往往不直观，需要逐条检查坐标才能定位。
系统性排查步骤与修复方案
遇到故障码2300时，建议按以下顺序排查。第一步确认字段类型，用typeof或$type查询定位所有坐标为字符串的文档：
// 查找location.coordinates中存在字符串类型元素的文档
db.stores.find({
"location.coordinates": { $type: "string" }
});
// 批量将字符串坐标转换为数值（通过aggregation pipeline更新）
db.stores.updateMany(
{ "location.coordinates": { $type: "string" } },
[{
$set: {
"location.coordinates": {
$map: {
input: "$location.coordinates",
as: "c",
in: { $toDouble: "$$c" }
}
}
}
}]
);
第二步校验坐标范围。经度必须在-180到180之间，纬度必须在-90到90之间。可以写一段脚本扫描全表，找出越界记录并判断是数据本身错误还是经纬度颠倒。如果确认是颠倒，用$reverseArray反转数组即可修复：
// 修复经纬度颠倒的数据
db.stores.updateMany(
{ "location.coordinates.1": { $gt: 90 } },
[{
$set: {
"location.coordinates": { $reverseArray: "$location.coordinates" }
}
}]
);
第三步处理多边形数据。检查外环是否闭合，如果不闭合则将首点追加到末尾；检查是否存在自相交，可以借助外部几何库（如Python的shapely）做isValid校验后再回写。对于精度误差导致的非闭合问题，可以在写入前对坐标做位数规整，例如统一保留6位小数（约0.1米精度，对绝大多数业务足够），这样既消除浮点噪声又减小索引体积。
最后需要注意索引层面的操作。如果坏数据已经进入集合并尝试建索引，索引构建会中途失败，此时集合可能残留不可用的索引记录。清理数据后应先执行db.stores.dropIndex("location_2dsphere")删除失败的索引，再重新创建。创建时可以显式指定索引版本，推荐使用Version 3以获得更好的查询兼容性：
db.stores.createIndex(
{ location: "2dsphere" },
{ "2dsphereIndexVersion": 3 }
);
预防方面，建议在应用层写入前增加统一的校验中间件：检查类型是否为数值数组、长度是否符合几何类型要求、范围是否合法、多边形是否闭合。同时尽量避免从多个数据源直接拼装几何对象而不做清洗，从源头杜绝脏数据，比事后修复的成本低得多。掌握以上排查思路，故障码2300基本都能在短时间内定位并解决。
MongoDB2dsphere索引故障码2300修改时间：2026-09-02 09:28:32