geodjango 是 django 中唯一官方支持空间数据库原生查询的方案，因其直接集成 postgis 空间索引、自动映射几何字段、下推 st_dwithin 等操作，并依赖 gdal/proj 实现高精度坐标转换，而 shapely 和 geopandas 仅限内存计算，无法替代其数据库直连能力。
GeoDjango 不是“首选”——它是 Django 项目中处理地理位置数据时唯一能直接对接空间数据库、提供原生空间查询能力的官方方案。如果你用 Django，又需要做距离查询、多边形包含判断、坐标系转换或空间索引，不选 GeoDjango 就得自己绕路拼 SQL 或调外部服务，效率和可靠性都掉一档。
Python 3.14.2是Python编程语言在2025年12月5日发布的稳定版本，属于3.14系列的第二个维护更新。该版本包含了18项修复，重点解决了多进程、数据类及正则表达式等模块的回归问题，并修复了CVE-2025-12084等安全漏洞。此版本标志着自由线程模式（移除GIL）正式获得官方支持，是Python发展的重要里程碑。
为什么不用纯 Django + Shapely 或 GeoPandas？
Shapely 和 GeoPandas 很好，但它们运行在 Python 层，所有计算都在内存里做：
- 无法利用 PostgreSQL 的 PostGIS 空间索引（比如 KNN 近邻查询）
- 无法把 ST_Within、ST_DWithin 这类操作下推到数据库执行
- 数据量稍大（比如 10 万+ 条 POI）时，GeoPandas.read_postgis() 拉全量再算，延迟明显，且容易 OOM
- 坐标系转换（如 WGS84 ↔ Web Mercator）若只靠 pyproj 手动转，漏掉 SRID 元数据或未设 transform 参数，distance_lte 查询会返回错误结果
PostGIS + GeoDjango 的实际协作链路
真正起效的是三者配合：PostGIS 存、GDAL/PROJ 转、GeoDjango 调：
- GeoDjango 的 PointField、PolygonField 字段会自动映射为 PostGIS 的 GEOMETRY 类型
- objects.filter(location__dwithin=(point, distance)) 直接生成带 ST_DWithin 的 SQL，走空间索引
- transform() 方法背后调用的是 GDAL 的 OGRGeometry.transform()，不是纯 Python 实现，精度和性能有保障
- GeoDjango 默认要求 GEOS ≥ 3.10，否则 union() 或 difference() 可能静默失败（尤其在复杂多边形叠加时）
常见踩坑点：环境变量和路径没配对
GeoDjango 启动时报 GEOSException: Could not load GEOS library 或 GDALException: Could not load GDAL library，90% 是因为：
- macOS 上用 brew install geos gdal proj 装了库，但没设 GEOS_LIBRARY_PATH 和 GDAL_LIBRARY_PATH
- Linux（如 Ubuntu）装了 libgeos-dev，但 Python 找不到 libgeos_c.so.1，需手动加软链或改 /etc/ld.so.conf.d/
- Windows 用户直接 pip install gdal 往往失败，必须用 conda install -c conda-forge gdal，且要确保 Django 版本与 GDAL 主版本兼容（例如 Django 4.2 需 GDAL ≥ 3.4）
GeoDjango 的价值不在“多酷”，而在它把空间数据库的能力稳稳地焊进 Django ORM 里——只要你的业务真要查“5km 内加油站”，或者“某地块是否跨行政区”，就绕不开它。其他库能帮你画图、转格式、做离线分析，但没法替代这条数据库直连通路。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
