Leaflet地图开发必看：如何正确选择CRS配置项避免坐标偏移（附EPSG3857/WGS84对比）

Leaflet地图开发必看：如何正确选择CRS配置项避免坐标偏移（附EPSG3857/WGS84对比）

刚接触Leaflet那会儿，我被一个看似简单的问题折腾了好几天：明明从GeoJSON文件里加载的边界线，在地图上显示的位置却差了十万八千里，怎么拖拽都对不上。起初以为是数据源有问题，反复检查坐标格式；后来又怀疑是瓦片图层不匹配，换了好几个服务商。最后，在一位经验丰富的前端同事指点下，我才把目光投向那个在初始化地图时几乎被我忽略的参数——crs。这个参数就像地图的“语言系统”，你说中文，地图却用英文解析，坐标自然就“鸡同鸭讲”，产生令人头疼的偏移。对于国内开发者而言，这个问题尤其普遍，因为我们常常需要混合使用百度、高德、谷歌等不同“语言体系”的地图服务。今天，我们就来彻底拆解Leaflet中的CRS配置，从原理到实战，帮你建立起清晰的坐标系认知，一劳永逸地解决坐标偏移这个“顽疾”。无论你是正在处理GIS数据可视化的前端工程师，还是希望将地理位置功能集成到应用中的全栈开发者，理解并正确配置CRS都是构建精准地图应用的基石。

1. 坐标系：地图世界的“方言”与“普通话”

要理解CRS，我们得先抛开代码，聊聊地图是怎么“画”出来的。地球是一个近乎球体的三维椭球，而我们的屏幕是一块二维的平面。把三维球面“压平”到二维平面上，这个过程就是地图投影。不同的投影方法，就像用不同的方言描述同一个地方，虽然指代的是同一个地理位置，但表达出来的“坐标值”可能天差地别。

Leaflet作为一个前端地图库，它本身不生产“地图”（即底图瓦片），它只是地图的“搬运工”和“展示者”。它的核心任务是：将来自不同来源的瓦片图片、点线面矢量数据，按照统一的规则，精准地拼合、定位、渲染在网页的同一个<div>容器里。这个“统一的规则”，就是坐标参考系统（Coordinate Reference System, CRS）。

提示：你可以把CRS想象成地图的“GPS协议”。它定义了坐标的数字含义（比如[116.404, 39.915]这个数组，哪个是经度？单位是什么？）、坐标原点在哪里、以及如何将经纬度换算成屏幕上的像素位置。

在Web地图领域，有几个CRS“方言”是你必须熟悉的：

• WGS84 (EPSG:4326)：这是地理坐标系中的“世界语”或“普通话”。它用我们熟悉的经度（Longitude）和纬度（Latitude） 来直接表示地球上的一个点。单位是度。GPS设备、KML文件、以及大多数国际标准的GIS数据（如来自政府开放数据门户的Shapefile）都使用这个坐标系。它的坐标范围是经度[-180, 180]，纬度[-90, 90]。
• Web Mercator (EPSG:3857)：这是Web地图事实上的“通用语”。为了适应瓦片地图的切片和快速加载，WGS84坐标需要被投影成一个正方形平面。Web墨卡托投影（伪墨卡托投影）就干了这个事。它将WGS84坐标投影到一个平面上，坐标单位变成了米。我们常看到的谷歌地图、OpenStreetMap、以及国内高德地图、腾讯地图的Web版，其瓦片服务都是基于这个坐标系。在Leaflet中，L.CRS.EPSG3857是默认的CRS。
• 其他“方言”：比如百度地图的BD-09坐标系。它在Web墨卡托的基础上，又进行了一次加密和偏移，可以理解为一种“方言的方言”。如果你直接使用百度地图的瓦片，但用EPSG:3857去解析，就会出现明显的偏移。

那么，偏移是如何产生的呢？想象一个场景：你有一份用WGS84坐标系记录的北京天安门坐标[116.397428, 39.90923]。如果你在Leaflet里创建地图时，默认使用L.CRS.EPSG3857，并且加载了同样是EPSG:3857的OpenStreetMap瓦片，一切正常。但如果你错误地认为这份数据是EPSG:3857坐标（单位是米），或者你加载的瓦片是另一种坐标系（比如未经纠偏的谷歌地球瓦片），Leaflet就会用错误的“翻译规则”去放置这个点，偏移就此产生。

下面的表格清晰地对比了这几种常见坐标系的特性：