作为踩过类似坑的开发者，给你梳理几个能快速定位问题的排查方向，你可以逐一核对：

• 死磕GeoJSON格式的细节合法性
  MongoDB的2dsphere索引对GeoJSON的要求近乎苛刻，哪怕微小的格式错误都会触发"无法提取geokeys"的报错：

  • 必须严格遵循{ type: "Point", coordinates: [经度, 纬度] }结构，一定是先经度后纬度，这是最容易踩的坑；
  • type字段必须是首字母大写的字符串（比如"Point"不能写成"point"或Point）；
  • coordinates必须是纯数字数组，不能是字符串类型的数字（比如["116", "39"]这种绝对不行）；
  • 如果是Polygon等复杂几何类型，必须保证坐标闭合（最后一个点和第一个点完全重合），嵌套数组的层级也不能错。

• 排查集合中的"坏文档"
  有时候99%的文档格式都正确，但个别异常文档会导致整个索引创建失败。你可以用以下命令快速定位问题文档：

  // 找出不在合法地理范围内的文档
  db.yourCollection.find({
    "geoField": {
      $not: {
        $geoWithin: {
          $geometry: {
            type: "Polygon",
            coordinates: [[[-180, -90], [180, -90], [180, 90], [-180, 90], [-180, -90]]]
          }
        }
      }
    }
  })
  

  另外也可以执行db.yourCollection.validate({ full: true })，检查集合是否存在损坏或结构异常的文档。

• 针对2.4/2.6版本的特殊校验规则
  这两个旧版本对GeoJSON的兼容性不如新版本，有几个专属坑：

  • 2.4版本的2dsphere索引只支持标准GeoJSON格式，完全不兼容旧的[经度,纬度]直接存储的格式（那是2d索引的用法）；
  • 2.6版本对坐标范围的校验更严格，只要经度超出[-180,180]、纬度超出[-90,90]，直接就会报错无法提取geokeys。

• 用最小测试集验证你的假设
  你提到有一个不确定的可能解释，可以先拿极简测试集验证：
  先插入一个标准测试文档：

  db.testGeo.insert({ loc: { type: "Point", coordinates: [116.397, 39.908] } })
  

  然后尝试创建索引：

  db.testGeo.createIndex({ loc: "2dsphere" })
  

  如果这个测试能成功，说明问题出在你现有集合的文档上；如果测试也失败，那可能是版本配置的特殊问题（比如2.4版本是否意外关闭了地理索引支持？不过默认是启用的）。

要是能贴出具体的报错日志片段，或者某个可疑文档的地理字段示例，定位问题会更快。

内容的提问来源于stack exchange，提问作者Moj