OpenLayers为何采用[lon, lat]坐标顺序而非常规[lat, lon]排布规则

先澄清一个认知偏差 #

• 你觉得这个顺序和UTM规则有关，本质是看到了表面的巧合：UTM里“东坐标（E）在前、北坐标（N）在后”的写法，和OpenLayers的经度在前、纬度在后的规则方向一致，但二者共同的源头是所有平面坐标通用的笛卡尔坐标表达逻辑——也就是横轴数值在前、纵轴数值在后。其中横轴就是朝东的方向，对应经度的指向；纵轴就是朝北的方向，对应纬度的指向。UTM只是这套逻辑的应用场景之一，不是规则的来源。
• 你熟悉的“纬度在前、经度在后”的写法，是民用导航、科普内容里为了读着顺口养成的文本表达习惯，从来不是工程计算场景的通用坐标规则。

OpenLayers选择这套规则的实际原因 #

• 这不是一个为了难倒用户专门设计的“非常规设定”，反而是为了适配全场景的工程化选择：OpenLayers不是只能显示WGS84经纬度的玩具库，它需要兼容UTM、Web墨卡托等几十种不同的投影坐标系。如果它硬把经纬度的输入顺序改成大众习惯的“纬度在前、经度在后”，碰到平面投影坐标的时候就会逻辑打架——所有平面投影坐标从来都是东值在前、北值在后，硬改顺序只会让跨坐标系转换的逻辑彻底乱掉。
• 这套顺序是整个GIS行业的通用标准，不是OpenLayers自己拍脑袋定的。从GeoJSON数据格式规范、WMS地图服务接口，到绝大多数GIS后端的接口定义，全都是经度（东向x值）在前、纬度（北向y值）在后。如果OpenLayers单独把顺序反过来，所有和其他工具对接的场景都会出现坐标偏移，比如把国内的点位直接错标到赤道上，这种故障的排查成本极高。
• 你贴的这段官方示例正好能说明这套设计的分层逻辑：

var coord = [7.85, 47.983333];
var out = toStringHDMS(coord);
// out is now '47° 58′ 60″ N 7° 50′ 60″ E'

程序内部计算的时候，严格把第一个数当x（经度，对应东向）、第二个数当y（纬度，对应北向）来处理；只有在生成给人看的度分秒文本时，才把两个值调换顺序，按大家习惯的“纬度在前、经度在后”的格式排版。计算层和展示层完全分离，根本不会影响普通用户读结果。

关于“要不要改规则降低门槛”的疑问 #

• 真要是为了所谓的大众习惯把底层坐标顺序反过来，带来的损失远大于收益：现在基于OpenLayers开发的海量业务系统、第三方插件，全都是按[lon, lat]的顺序传值的，改完等于让所有老项目全部出故障，这种成本没有哪个库能承担。
• 对于新手的门槛问题，其实适配的成本极低：如果你从普通GPS设备拿到的是[lat, lon]顺序的坐标，只需要把数组两个元素换个位置就能用，根本不需要让库去迁就所有用户的个人习惯。

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