最近在项目里反复踩坐标系的坑，有点烦，但也确实逼着自己把这几种常见的 EPSG 坐标系重新梳理了一遍。
一开始我以为只是“转换一下”的问题，后来发现，其实是我对它们的理解一直是碎片化的。
这篇就当是给自己做个记录。
1. 先想清楚一件事：坐标到底是什么
以前总是直接用，从来没认真想过。
现在回过头看，其实本质很简单：
地球是个椭球体，但程序处理的是平面 所以所有坐标系，本质都是一种“表达方式”
区别不在于“哪个更对”，而在于：
你现在用的是哪一种表达方式。
2. 4326 和 4490：看起来一样，其实不是一回事
这两个是我之前最容易混的。
- 4326：WGS84（GPS 用的）
- 4490：CGCS2000（国内标准）
它们的形式是一样的：经度，纬度
比如：[120.xxxx, 30.xxxx]
一开始我就觉得它们是同一个东西，只是名字不一样。
但实际上：
- 底层参考椭球不同
- 只是“数值接近”，不是“完全一致”
在小范围内确实没啥区别，但如果严格一点，是不能混用的。
不过说实话，在很多项目里大家还是混着用，这也是问题的来源之一。
3. 3857：地图显示用的坐标系
这个其实是我后来才真正理解的。
3857（Web Mercator）本质上不是“真实坐标”，而是：为了在屏幕上画地图而设计的坐标系
特点很明确：
- 单位是米
- 可以直接拿来画图
- 所有互联网地图基本都用它
但它有个很关键的点：它是“变形的”
也就是说：
- 它适合显示
- 不适合做精确计算
所以：3857 更像是“展示层坐标系”。
4. 4549：真正让我踩坑的地方
如果说前面几个只是“理解问题”，那 4549 是实打实让我数据直接错位的东西。
4.1 它到底是什么
4549 是 CGCS2000 下的高斯投影（3度带），带中央经线 120°。
重点不在名字，而在这几个关键词：
- 投影坐标系
- 单位是米
- 有“中央经线”
4.2 最关键的问题：中央经线
这个是我一开始完全没意识到的点。
同样一份数据，如果：
- 实际是 117°中央经线
- 你按 120°去解释
结果就是：整体偏移几十公里甚至上百公里
而且这种偏移是“看起来很正常，但就是对不上”的那种，很难第一时间怀疑到这里。
4.3 我项目里的真实情况
后来排查才发现：
- 数据其实是 118.5° 的
- 但数据库标的是类似 4549（120°）
- 前端又在用另一套逻辑去转
结果就是：整条链路每一步都“有一点点错”
最后表现出来就是：全错
5. 这些问题为什么这么容易发生
现在回头看，其实原因很简单：
1）坐标系是“隐形信息”
不像字段、接口那样直观，
你不主动看 SRID，就根本不知道它是什么。
2）很多系统默认帮你“猜”
比如：
- 前端自动转
- 中间层做兼容
- VTS 配 proj4
这些东西在“看起来正常”的时候，其实在掩盖问题。
3）大家习惯“先跑起来再说”
包括我自己也是：能显示就行
但坐标系这种东西：一开始不统一，后面只会越来越乱
6. 我现在给自己的几个原则
不算什么标准，就是踩坑之后给自己的提醒：
（1）必须搞清楚数据源坐标系
不是“猜”，不是“感觉像”，而是：确认原始数据到底是什么坐标系
（2）不要混用 4326 和 4490
哪怕它们很像，也尽量统一。
（3）涉及 4549，一定问中央经线
如果没人能说清楚：那这个数据就是不可信的。
（4）前端统一用 3857 渲染
后端再复杂，最终都转成一个标准再给前端。
（5）多看 SRID，而不是只看数值
ST_SRID(shape)
有时候问题不在数据，而在“你以为它是什么”。
7. 最后的一点感受
以前觉得 GIS 开发就是：地图 + 接口 + 渲染，
现在慢慢意识到：真正难的不是代码，而是这些“基础认知”。
坐标系、投影、数据来源，这些东西一旦理解不清楚：后面所有逻辑都是建立在错误基础上的，
而且最麻烦的是：它不会报错，只会悄悄让你结果不对。
这篇就先记到这。
以后如果再遇到“地图不对”的问题，希望自己第一反应不是去改代码，
而是先问一句：现在这一步，用的到底是什么坐标系。
