高德导航API返回的路径规划数据中，coordinates字段为何是经纬度倒序？

Question

在使用高德地图Web/JS API（如`AMap.Driving`或`AMap.Riding`）进行路径规划时，开发者常困惑：为何返回的`steps[].polyline`或`routes[].path`中的`coordinates`数组是`[经度, 纬度]`顺序（如`[116.48, 39.99]`），而非地理学惯例的`[纬度, 经度]`？这看似“倒序”，实为**国际通用的GeoJSON规范约定**：所有遵循GeoJSON标准（RFC 7946）的空间坐标均采用`[longitude, latitude]`（即x, y）顺序，以对齐笛卡尔平面坐标系。高德API虽未显式声明兼容GeoJSON，但其`polyline`解码后的坐标序列、以及`AMap.LngLat`对象内部存储逻辑，均严格遵循此规范。混淆源于部分GIS教材或旧版WGS84文档强调“纬度在前”，而现代Web地图（包括Leaflet、Mapbox、高德、百度）统一采用`LngLat`结构（经度优先）。若误按`[lat, lng]`解析，将导致轨迹严重偏移。正确做法是始终以`new AMap.LngLat(lng, lat)`构造点，并确认坐标数组索引0为经度、1为纬度。

Answer 1

```html

一、现象层：开发者初见坐标顺序时的典型困惑

在调用 AMap.Driving.search() 或 AMap.Riding.search() 后，解析 result.routes[0].path 或 step.polyline 时，常见日志输出为：[[116.4812, 39.9895], [116.4821, 39.9903], ...]。大量5年以上经验的前端/全栈工程师仍会本能质疑：“为什么不是 [lat, lng]？这不符合《GIS原理》课本里WGS84的表述！”——该困惑本质是**坐标系语义与工程实践脱节的第一道认知断层**。

二、规范层：GeoJSON RFC 7946 是现代Web地图的底层宪法

• RFC 7946 第3.1.1节明确定义：“The order of elements must be longitude, then latitude”；
• 其设计哲学源于笛卡尔坐标系一致性：longitude → x轴（东西向），latitude → y轴（南北向）；
• 所有主流Web地图引擎（Leaflet、Mapbox GL JS、OpenLayers、高德JS API、百度地图JS SDK）均将 LngLat 作为第一公民类型，内部存储结构为 {lng: number, lat: number}；
• 高德虽未在文档首页标注“符合RFC 7946”，但其 AMap.GeometryUtil.decodePolyline() 输出、AMap.LngLat.toString() 格式、以及 AMap.Marker.setPosition(new AMap.LngLat(lng, lat)) 的构造签名，构成完整的规范闭环。

三、历史层：为何教科书与工程实践出现“纬度优先”的认知惯性？

来源	坐标顺序	技术背景	遗留影响
经典GIS教材（如《地理信息系统导论》）	[lat, lng]	面向测绘/遥感专业，强调地理球面坐标系（φ, λ）	高校教学长期强化“纬度是第一参数”直觉
早期WGS84文档（NIMA TR8350.2）	[lat, lng]	以大地测量学视角定义椭球参数	传统GIS桌面软件（ArcGIS Desktop）默认采用此序
GeoJSON（RFC 7946, 2016）	[lng, lat]	为Web交互设计，对齐CSS/Canvas坐标系	成为现代Web地图事实标准

四、验证层：通过三重实证确认高德API的坐标逻辑

1. 解码验证：对 "bcp|Ckqj" polyline字符串执行 AMap.GeometryUtil.decodePolyline("bcp|Ckqj") → 返回 [[116.48, 39.99]]；
2. 构造验证：new AMap.LngLat(116.48, 39.99).toArray() → [116.48, 39.99]；
3. 渲染验证：将该坐标传入 new AMap.Marker({position: new AMap.LngLat(116.48, 39.99)})，标记精准落在北京国贸区域，反向证明顺序正确。

五、风险层：误用 [lat, lng] 解析引发的生产事故模式

graph LR
A[开发者读取 routes[0].path] --> B{错误假设：索引0=纬度}
B -->|true| C[用 position = new AMap.LngLat(lat, lng) 构造]
C --> D[实际传入 new AMap.LngLat(39.99, 116.48)]
D --> E[坐标被解释为南纬39.99°、东经116.48°]
E --> F[标记出现在南大西洋海域，轨迹整体偏移超10000km]
B -->|false| G[正确解析：索引0=经度]
G --> H[轨迹渲染符合真实道路走向]

六、实践层：防御性编码的四条黄金准则

1. 永远显式命名变量：使用 const lng = coords[0]; const lat = coords[1];，禁用 const [x, y] = coords; 等模糊解构；
2. 封装校验函数：

   function parseLngLatArray(coords) {
     if (!Array.isArray(coords) || coords.length !== 2) 
       throw new Error('Invalid coordinate array');
     const [lng, lat] = coords;
     if (Math.abs(lng) > 180 || Math.abs(lat) > 90) 
       throw new Error(`Invalid LngLat: [${lng}, ${lat}]`);
     return new AMap.LngLat(lng, lat);
   }

3. 统一坐标转换入口：所有第三方数据（如GeoJSON FeatureCollection）进入高德体系前，强制执行 feature.geometry.coordinates.map(([lng, lat]) => [lng, lat])；
4. CI阶段注入坐标断言：在E2E测试中对路径点执行 expect(point.lng).toBeGreaterThan(116) 等地理围栏校验。

```