应使用 pyproj.transformer 的批量 transform(lats, lons) 接口而非单点循环，输入需为 float64 数组，注意顺序为（纬度、经度），返回（y, x）；跨带时动态选 utm zone；优先用 epsg 代码避免 datum/ellps 混用；crs 等价性用 == 判断，并用 to_wkt() 核查定义。
直接用 pyproj.Transformer 批量转换，别用单点循环调用 transform() —— 否则 10 万点可能慢 30 倍以上。
批量转换必须用 Transformer.transform 的数组接口
常见错误是写成 for lon, lat in coords: x, y = transformer.transform(lat, lon)。这会反复触发 PROJ 内部坐标系解析和缓存重建，性能极差。
- 正确做法：把所有纬度、经度分别堆成 NumPy 数组或 Python 列表，一次性传入
transform() -
transformer.transform(lats, lons)返回两个等长数组，顺序是(y, x)（注意：先纬度后经度） - 如果输入是 GeoPandas
GeoDataFrame，优先用to_crs()方法，它底层已自动启用批量路径 - 避免混合数据类型：确保输入数组 dtype 是
float64，float32可能导致精度丢失（尤其高斯投影东偏移 500000 米附近）
处理跨带或边缘区域时，别硬塞进一个 UTM zone
UTM 分带本质是局部近似，当坐标横跨两个 zone（比如经度 119.9° 和 120.1°），强行统一转到 EPSG:32651 会导致东向坐标突变 >100km。
- 先用
math.floor((lon + 180) / 6) + 1算出 UTM zone 编号，再动态构造CRS.from_dict({"proj": "utm", "zone": z, "south": False}) - 对国内高斯-克吕格 3° 带，中央经线 =
round(longitude / 3) * 3，但需校验是否在 ±1.5° 范围内，否则跳到相邻带 - 更稳妥方案：用
pyproj.CRS.from_user_input("EPSG:4326")+pyproj.database.query_utm_crs_info查找最适 zone，支持自动 fallback
自定义投影参数时，datum 和 ellps 不能混用
例如想用 CGCS2000 椭球但手动指定 ellps=CGCS2000，同时又写 datum=WGS84，PROJ 会静默忽略后者，实际仍按 WGS84 计算，偏差可达 0.5–1 米。
- 国内项目优先用完整 EPSG 代码（如
EPSG:4490表示 CGCS2000 地理坐标系），避免手拼 proj 字符串 - 必须手写时，只保留
datum或只保留ellps，二者选其一；若需 datum 转换（如 WGS84 → 北京54），显式加towgs84参数 - 检查 CRS 是否等价：用
crs1 == crs2，而不是字符串比对 —— PROJ 会归一化表达式
真正棘手的不是转换逻辑，而是坐标参考系统本身的歧义性：同一个“西安80”可能对应不同椭球参数或不同中央经线。批量处理前，务必用 CRS.to_wkt() 输出完整定义并人工核对头几行，否则错 10 万点，改起来比重跑还费劲。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
