Windows 上写入 GeoPackage 后 pandas 操作导致内核退出，如何排查？

结论

现有信息不足以判断是哪个包或库导致了崩溃。问题可能与 Windows 上的原生依赖或特定的 Conda 构建组合有关；“GDAL/SQLite 改变进程状态并与 Excel 操作冲突”目前仍是待验证的假设。

当前的复现步骤是先用 GeoDataFrame.to_file() 写入 .gpkg，再调用 pandas 的 Excel 操作；改用 .geojson 后则运行正常。崩溃发生在 to_excel() 或 read_excel()，更换 Excel 引擎也没有解决问题。这些现象可以帮助缩小排查范围，但不能据此认定故障来自 openpyxl、GDAL 或 SQLite。

先确认崩溃是否依赖同一进程

分别在全新的 Python 进程中测试 Excel 操作、GeoPackage 操作，以及先写入 GeoPackage 再操作 Excel。保留现有的复现顺序，并记录每一步的退出码和输出。这样可以判断单项操作是否会崩溃，还是只有在同一进程中依次执行时才会出问题。

如果只有组合操作会导致崩溃，可以暂时把 GeoPackage 写入和 Excel 读写放到两个独立进程中，作为规避方案。如果拆分进程后仍然崩溃，就继续分别检查这两项操作及其环境依赖。

比较成功与失败的 Conda 环境

已有结果显示，使用 -c defaults -c conda-forge 可以运行，而仅使用 -c conda-forge 会出问题；通过环境文件安装和一次性安装包列表也得到不同结果。下一步应固定 Windows 平台、Python 版本和包列表，分别创建成功和失败的干净环境，避免在同一环境中反复安装或升级，导致对照条件发生变化。

在两种环境中保存以下信息：

conda info
conda list --show-channel-urls
conda list --explicit

重点比较相关包的版本、构建号和来源渠道。可以先检查实际安装的 pandas、geopandas、gdal、sqlite、pyogrio、fiona、openpyxl 等包，但应以环境输出为准，不要预先认定某个包就是根因。如果有依赖通过 pip 安装，也要一并记录。

逐步缩小包范围

从能复现问题的最小环境开始，分阶段加入生产环境所需的包，每加入一组就运行相同的复现脚本。发现结果首次发生变化后，再继续拆分这一组。比较安装渠道时，要保持其他条件一致，并以实际解析出的包版本和构建为准。只比较环境文件文本或安装命令，无法确认最终环境相同。

保留可用的诊断信息

内核突然退出时，通常不会像普通 Python 异常那样提供完整 traceback。可以在每个阶段前后输出标记，并将输出写入日志，以确认最后完成的操作。若要进一步分析，还应保存崩溃进程信息和对应的环境清单。仅凭 print() 输出或“Kernel has died”提示，无法定位原生层的具体故障点。

接下来应先取得成功和失败环境的完整包清单，确认崩溃是否只发生在同一进程中的组合调用，再按阶段缩小依赖范围。在找到可稳定复现的具体包组合或崩溃记录前，无法把原因归结为某个引擎或原生库。

备注：内容仅供参考。