Jupyter 地图最容易产生一种错觉：单元格运行成功，成果便可复现。Leafmap v0.63.1 于 2026 年 8 月 2 日发布，更新了文档站点与自动化评审工作流；它提示团队，笔记本成果还依赖地图后端、外部数据入口和分析工具。
可核查事实
- v0.63.1 将文档从 MkDocs 迁至 Zensical，并更新自动化评审和 Python 设置。
- README 将 Leafmap 定位为 Jupyter 交互制图和地理分析包，也是 geemap 的衍生项目。
- 支持 ipyleaflet、folium、kepler.gl、pydeck、bokeh 等后端。
- 可访问 STAC、Planetary Computer、AWS Open Data Registry 和 OpenAerialMap。
- 集成 WhiteboxTools 的 500 多种分析工具。
核心机制
Leafmap 将笔记本中的数据加载、交互地图和分析工具连接起来，但这些层并不共享同一稳定性。后端决定交互与输出形态，数据服务决定可取得的影像和元数据，WhiteboxTools 决定分析执行环境。把它们都写成“一个 Leafmap 地图”，会让复现失败无法定位。
技术路径
固定 Python、Leafmap 和后端版本，导出笔记本依赖。对同一 AOI 分别记录数据服务查询、资产 ID、时间范围和坐标系。渲染层仅验证图层、图例和交互；分析层单独保存参数、输入输出和工具版本。更换后端或升级环境后，依次重跑数据发现、地图呈现和分析结果，不能只看截图。
GIS 场景
遥感教学团队可用 STAC 检索影像、在 Leafmap 中检查范围，再用 WhiteboxTools 处理地形。发布前应让另一台机器从锁定环境重跑：先确认查询仍返回同一资产，再确认地图后端能显示，最后比较分析输出。
检查清单
- 是否保存 Leafmap、Python 和地图后端版本？
- 是否记录 STAC 或其他服务的查询、资产 ID 和时间范围？
- 是否把交互显示与 WhiteboxTools 分析分开验证？
- 是否在干净环境重跑笔记本？
- 是否把外部服务不可用视为可处理错误？
- 是否核验输出坐标系、范围和分析参数？
风险边界
README 的功能清单不是外部数据服务可用性承诺；不同后端的交互和导出也不必然等价。v0.63.1 的文档与 CI 改动不能替代对团队环境的实测。
结语
把 Leafmap 笔记本拆成数据、后端和分析三层记录，才能让一次演示变为可交接的 GIS 工作流。