Jupyter Notebook运行代码无反应？GIS空间分析环境排查与修复详解（附：内核配置表）

wowwwai GIS研习社 · 工具流程与项目排障

Jupyter Notebook运行代码无反应？GIS空间分析环境排查与修复详解（附：内核配置表）这类问题在 GIS 学习和空间分析项目中很常见：单元格左侧一直显示 In [*]，点击运行没有输出，GeoPandas、Rasterio、ArcPy 或 GDAL 相关代码卡住，甚至 Notebook 页面看起来正常但内核完全不响应。

这篇文章按 GIS 空间分析环境的真实使用场景，帮你从浏览器、Jupyter 服务、Python 内核、Conda 环境、GIS 依赖库、数据路径和资源占用几个层面逐步排查。重点不是“重装一遍”，而是判断到底卡在哪里，并给出可复现的修复方法。

引言：先判断“无反应”是哪一种

很多同学说 Jupyter Notebook 运行代码无反应，其实可能对应几种不同情况。不同现象背后的原因不一样，修复方法也不同。

现象	常见表现	优先排查方向
单元格一直是 In [*]	运行后没有输出，内核一直忙	代码阻塞、GIS库加载慢、数据太大、死循环
点击运行完全没变化	单元格编号不变，页面按钮无响应	浏览器、前端连接、Jupyter Server
Kernel restarting	内核反复重启	Python环境冲突、二进制库冲突、内存溢出
导入 GIS 库时卡住	import geopandas、import arcpy、import rasterio 长时间无输出	Conda环境、GDAL/PROJ依赖、ArcGIS授权或版本
读取数据时卡住	read_file、read_filegdb、read raster 无输出	文件路径、网络盘、数据损坏、编码、文件体积

建议你不要一开始就删除环境或重装 Anaconda。正确做法是先用最小代码测试内核，再逐步加入 GIS 依赖和空间数据。

背景：为什么 GIS 环境更容易遇到 Jupyter Notebook运行代码无反应

普通 Python Notebook 通常只依赖 NumPy、Pandas、Matplotlib 等库，而 GIS 空间分析环境往往还依赖 GDAL、GEOS、PROJ、Fiona、Rasterio、PyProj、Shapely、GeoPandas、ArcPy 等组件。

这些组件有几个特点：

• 二进制依赖多：GDAL、GEOS、PROJ 不是纯 Python 包，版本不匹配时可能导致内核卡死或直接崩溃。
• 环境隔离复杂：Notebook 当前内核可能不是你安装 GeoPandas 的 Conda 环境。
• 数据读取成本高：Shapefile、GeoPackage、FileGDB、大栅格、网络路径数据都可能让代码长时间处于运行状态。
• 坐标转换耗时：批量投影转换、空间连接、缓冲区、叠加分析等操作对 CPU 和内存要求较高。
• ArcPy 环境特殊：ArcPy 通常依赖 ArcGIS Pro 自带 Python 环境，不能随意混装到普通 Conda 环境。

所以，Jupyter Notebook运行代码无反应在 GIS 场景里，很多时候不是 Notebook 本身坏了，而是“前端、内核、环境、依赖、数据、资源”其中一环出现阻塞。

原理：Notebook 运行代码的调用链路

理解 Jupyter 的基本链路，有助于快速定位问题。

1. 浏览器中的 Notebook 页面发送执行请求。
2. Jupyter Server 接收请求。
3. Server 将代码交给当前 Python Kernel。
4. Kernel 执行 Python 代码。
5. 如果代码调用 GeoPandas、GDAL、Rasterio、ArcPy 等 GIS 库，就继续调用底层依赖。
6. 如果代码读取空间数据，还会访问本地磁盘、移动硬盘、网络共享盘或数据库。
7. 执行结果返回到浏览器页面。

因此，看到单元格一直 In [*]，只能说明内核还没有返回结果，并不能直接说明代码一定错了。可能是内核真的在计算，也可能是底层库卡住、文件读取卡住、内存不够，或者内核已经失联。

步骤：从最小测试开始排查 Jupyter Notebook运行代码无反应

步骤一：确认浏览器和 Jupyter 页面是否正常

先不要运行复杂 GIS 代码，新建一个单元格，执行最简单的 Python 语句：

1 + 1

如果这个单元格也没有任何反应，优先检查浏览器和 Jupyter Server。

• 刷新页面后重新运行。
• 换用 Chrome、Edge 或 Firefox 测试。
• 关闭浏览器插件，特别是脚本拦截、代理、隐私保护类插件。
• 查看启动 Jupyter 的终端窗口是否有报错。
• 确认 Notebook 页面右上角内核状态不是 Disconnected。

如果刷新后提示重新连接内核，可以先选择重新连接；如果无效，再重启内核。

步骤二：测试 Python 内核是否还能执行代码

在 Notebook 中运行：

import sys
print(sys.executable)
print(sys.version)

这一步有两个目的：一是确认内核是否能正常执行；二是确认当前 Notebook 使用的 Python 路径。

如果输出的路径不是你预期的 GIS 环境，例如不是 conda envsgis、不是 ArcGIS Pro 的 Python 环境，那么后面导入 GeoPandas 或 ArcPy 出问题就很正常。

步骤三：确认 Notebook 内核和 Conda 环境是否一致

在命令行中查看已有 Conda 环境：

conda env list

进入你用于 GIS 分析的环境：

conda activate gis

安装或确认 ipykernel：

conda install ipykernel

将当前环境注册为 Jupyter 内核：

python -m ipykernel install --user --name gis --display-name "Python (GIS)"

然后回到 Notebook，选择：

Kernel → Change Kernel → Python (GIS)

再次运行：

import sys
print(sys.executable)

如果路径已经指向你的 GIS 环境，说明 Notebook 内核配置正确。

步骤四：分开测试 GIS 依赖库，不要一次性全部导入

很多 Notebook 教程开头会写一大串导入：

import geopandas as gpd
import rasterio
import pyproj
import shapely
import fiona
import matplotlib.pyplot as plt

如果其中一个库卡住，你很难判断问题在哪。建议逐个测试：

import shapely
print("shapely ok")

import pyproj
print("pyproj ok")

import fiona
print("fiona ok")

import geopandas as gpd
print("geopandas ok")

import rasterio
print("rasterio ok")

如果卡在 import geopandas，通常要检查 Fiona、GDAL、PROJ、PyProj、Shapely 的版本组合。如果卡在 import arcpy，则应确认当前内核是否是 ArcGIS Pro 的 Python 环境，并确认 ArcGIS Pro 授权可用。

步骤五：检查 GeoPandas、GDAL、Rasterio 的安装来源

GIS Python 库不建议在同一个环境中随意混用 pip 和 conda 安装，尤其是 GDAL、Fiona、Rasterio、GeoPandas 这类库。

推荐使用 conda-forge 创建独立环境：

conda create -n gis -c conda-forge python=3.11 geopandas rasterio pyproj shapely fiona jupyterlab notebook ipykernel

激活环境：

conda activate gis

注册内核：

python -m ipykernel install --user --name gis --display-name "Python (GIS)"

如果你的环境已经混乱，建议不要在原环境里反复修补。对 GIS 初学者来说，新建一个干净的 GIS 环境，往往比修复一个混装环境更稳定。

步骤六：读取空间数据前先检查文件路径和大小

Jupyter Notebook运行代码无反应经常发生在读取数据时，例如：

import geopandas as gpd
gdf = gpd.read_file("data/boundary.shp")

排查时先用 Python 检查文件是否存在：

from pathlib import Path

path = Path("data/boundary.shp")
print(path.exists())
print(path.resolve())

如果是 Shapefile，还要确认同名文件是否完整：

• .shp：几何数据
• .shx：索引文件
• .dbf：属性表
• .prj：坐标系信息，非必须但强烈建议保留
• .cpg：编码信息，中文属性常用

如果数据在网络盘、同步盘、移动硬盘或中文深层路径中，建议先复制到本地短路径测试，例如：

D:/gis_test/boundary.shp

很多看似 Notebook 无反应的问题，实际是网络路径读取缓慢、文件被占用、数据损坏或路径转义错误。

步骤七：判断是不是数据量太大或空间分析太重

如果简单代码正常，但空间连接、叠加分析、缓冲区、栅格读取时无反应，可能是计算量太大。

例如以下操作都可能明显耗时：

• 大范围行政区与海量点数据做 sjoin。
• 未建立空间索引时做叠加分析。
• 对高分辨率栅格一次性全部读入内存。
• 对经纬度坐标直接做缓冲区计算后再投影。
• 读取超大 GeoJSON 文件。

可以先只读取前几条记录测试：

import geopandas as gpd

gdf = gpd.read_file("D:/gis_test/boundary.shp")
print(gdf.head())
print(gdf.shape)
print(gdf.crs)

对于栅格数据，不要一上来整幅读入：

import rasterio

with rasterio.open("D:/gis_test/image.tif") as src:
    print(src.width, src.height)
    print(src.count)
    print(src.crs)
    window = rasterio.windows.Window(0, 0, 512, 512)
    arr = src.read(1, window=window)
    print(arr.shape)

如果小窗口读取正常，而整幅读取卡住，问题多半不是 Notebook，而是数据体积和内存压力。

步骤八：查看系统资源占用

当 Notebook 一直 In [*] 时，打开任务管理器或系统监视器，查看 CPU、内存和磁盘。

• CPU 持续很高：代码可能仍在计算。
• 内存接近满：可能发生交换内存，Notebook 看起来像卡死。
• 磁盘持续高占用：可能在读写大数据或临时文件。
• CPU 和磁盘都很低：可能是内核死锁、等待外部资源或连接异常。

如果内存不足，优先减少数据量、分块处理、建立空间索引，或把中间结果写入 GeoPackage、Parquet、PostGIS 等更适合分析的格式。

步骤九：重启内核时要分清 Restart 和 Restart & Run All

如果单元格已经卡住，可以先在 Notebook 中选择：

Kernel → Interrupt Kernel

如果中断无效，再选择：

Kernel → Restart Kernel

不要直接选择 Restart & Run All，否则可能又自动运行到同一个卡住的单元格，让你误以为重启无效。

重启后建议按以下顺序执行：

1. 运行 1 + 1。
2. 运行 sys.executable。
3. 逐个导入 GIS 库。
4. 只读取一个小数据。
5. 最后再运行完整空间分析流程。

常见坑：GIS 空间分析环境里最容易忽略的问题

坑一：Notebook 用的不是你安装库的那个环境

这是最常见的问题。你在命令行中安装了 GeoPandas，但 Notebook 内核仍然指向 base 环境或另一个 Python。

判断方法很简单：

import sys
print(sys.executable)

只要这个路径和你安装 GIS 库的环境不一致，就需要重新注册 ipykernel，并在 Notebook 中切换内核。

坑二：在 base 环境里堆满 GIS 依赖

很多初学者会直接在 base 环境安装所有库。短期看方便，长期看很容易出现依赖冲突。

建议为不同任务建立独立环境：

• gis：GeoPandas、Rasterio、PyProj、Jupyter。
• webgis：Folium、OSMnx、可视化相关库。
• arcgispro-py3：ArcPy 和 ArcGIS Pro 相关脚本。

坑三：ArcPy 不能按普通包随意安装

ArcPy 通常跟随 ArcGIS Pro 的 Python 环境安装。不要简单使用 pip install arcpy 期待它在普通环境中可用。

如果 Notebook 需要运行 ArcPy，推荐使用 ArcGIS Pro 自带的 Python 环境或其克隆环境，并把该环境注册到 Jupyter 内核中。

坑四：Shapefile 文件不完整

只有一个 .shp 文件通常是不够的。缺少 .shx 或 .dbf 时，读取可能报错，也可能在某些流程中表现为长时间无响应。

如果需要长期处理，建议把 Shapefile 转为 GeoPackage：

import geopandas as gpd

gdf = gpd.read_file("D:/gis_test/boundary.shp")
gdf.to_file("D:/gis_test/boundary.gpkg", layer="boundary", driver="GPKG")

坑五：GeoJSON 太大导致 WebGIS 和 Notebook 都卡

大 GeoJSON 是 WebGIS 和 Python 分析中都容易踩的坑。GeoJSON 可读性好，但不适合承载特别大的面数据或高精度边界。

如果读取 GeoJSON 时 Jupyter Notebook运行代码无反应，可以考虑：

• 先用 QGIS 或 ogr2ogr 简化几何。
• 转换为 GeoPackage 或 Parquet。
• 只保留必要字段。
• 按区域拆分数据。
• 导入 PostGIS 后用 SQL 分批处理。

坑六：空间分析没有空间索引

空间连接、相交、包含、邻近分析都依赖空间索引提高效率。GeoPandas 通常会使用 Shapely/GEOS 提供的空间索引能力，但数据结构和版本不同，性能表现会有差异。

可以检查空间索引是否可用：

print(gdf.sindex)

如果空间分析很慢，先确认坐标系、几何有效性、数据量和索引，而不是只怀疑 Notebook。

方法比较：不同修复方案适合什么情况

方法	适合情况	优点	注意事项
刷新页面	浏览器前端卡住或断开连接	最快，风险低	不能解决内核或环境问题
Interrupt Kernel	代码正在运行但想中断	保留当前变量的可能性较高	底层库阻塞时可能中断失败
Restart Kernel	内核无响应、变量状态混乱	清理内存和状态	所有变量会丢失
重新注册 ipykernel	Notebook 内核与 Conda 环境不一致	定位准确，修复彻底	需要在正确环境中执行
新建 conda-forge GIS 环境	GDAL、GeoPandas、Rasterio 依赖混乱	稳定性较好	需要重新安装必要包
使用 ArcGIS Pro Python 环境	需要 ArcPy	与 ArcGIS Pro 兼容	不要和普通 GIS 环境混用
转换数据格式	Shapefile、GeoJSON 读取慢或文件损坏	提升稳定性和性能	需确认字段、编码、坐标系无误
分块处理数据	大栅格、大矢量、内存不足	避免一次性占满内存	代码复杂度会增加

检查清单：按顺序排查最省时间

遇到 Jupyter Notebook运行代码无反应时，建议按下面清单逐项检查。

• 页面状态：Notebook 页面是否断开连接？刷新后是否恢复？
• 最小代码：1 + 1 是否能立即返回？
• 内核路径：sys.executable 是否指向正确 GIS 环境？
• 内核选择：是否已经切换到注册好的 Python (GIS) 内核？
• 库导入：是否逐个测试 shapely、pyproj、fiona、geopandas、rasterio？
• 安装来源：GDAL、Fiona、Rasterio、GeoPandas 是否尽量来自同一个 conda-forge 环境？
• ArcPy：是否使用 ArcGIS Pro 对应 Python 环境？授权是否正常？
• 数据路径：文件是否存在？路径是否包含转义问题？是否位于网络盘或同步盘？
• 数据完整性：Shapefile 的 .shp、.shx、.dbf 是否齐全？
• 数据体积：是否先用小样本、小窗口、小区域测试？
• 资源占用：CPU、内存、磁盘是否达到瓶颈？
• 空间索引：大规模空间查询是否建立或触发空间索引？
• 坐标系：是否在合适的投影坐标系下做距离、面积、缓冲区分析？
• 重启方式：是否避免盲目 Restart & Run All？

内核配置表：GIS 常用 Notebook 环境建议

使用场景	推荐内核	主要库	配置建议
矢量空间分析	Python (GIS)	GeoPandas、Shapely、PyProj、Fiona	使用 conda-forge 创建独立环境，并注册 ipykernel
栅格处理	Python (Raster)	Rasterio、Xarray、Rioxarray、NumPy	大栅格优先窗口读取，避免一次性读入整幅影像
ArcGIS Pro 自动化	ArcGIS Pro Python	ArcPy、ArcGIS API for Python	使用 ArcGIS Pro 自带环境或克隆环境，不建议混入普通 Conda 环境
WebGIS 数据预处理	Python (WebGIS)	GeoPandas、Folium、Tippecanoe相关工具、地图切片工具	大 GeoJSON 先简化、切片或转为更合适格式
PostGIS 分析	Python (PostGIS)	psycopg、SQLAlchemy、GeoPandas	大数据尽量在数据库侧完成空间过滤和索引查询
教学与轻量练习	Python (Base 或 LearnGIS)	Pandas、Matplotlib、GeoPandas	不要把教学环境和生产项目环境混在一起

如果你只做入门学习，建议先维护一个干净的 gis 环境。等需要 ArcPy、PostGIS 或大栅格处理时，再拆分专用环境。

FAQ：Jupyter Notebook运行代码无反应常见问题

Q1：单元格一直显示 In [*]，是不是 Notebook 崩了？

不一定。In [*] 只表示内核正在执行或等待返回。你需要结合 CPU、内存、磁盘占用判断。如果资源持续高占用，可能仍在计算；如果资源很低且长时间无输出，可能是内核阻塞或失联。

Q2：为什么命令行能 import geopandas，Notebook 里却无反应？

通常是 Notebook 选择的内核和命令行激活的 Conda 环境不是同一个。请在 Notebook 中运行 sys.executable，确认 Python 路径。如果不一致，需要在正确环境中安装 ipykernel 并重新注册内核。

Q3：import arcpy 卡住怎么办？

先确认当前 Notebook 是否使用 ArcGIS Pro 的 Python 环境。ArcPy 不适合随意安装到普通 Conda 环境。还要确认 ArcGIS Pro 授权、版本、环境变量和项目许可是否正常。

Q4：读取 Shapefile 时 Jupyter Notebook运行代码无反应，怎么判断是数据问题？

先检查 .shp、.shx、.dbf 是否齐全，再把数据复制到本地短路径。然后用 QGIS 打开验证。如果 QGIS 打开也很慢或报错，优先怀疑数据损坏、编码异常或几何复杂度过高。

Q5：GeoJSON 文件一读就卡，有什么更好的格式？

如果 GeoJSON 很大，建议转为 GeoPackage、FlatGeobuf、Parquet 或导入 PostGIS。GeoJSON 适合交换和轻量 Web 展示，不适合承载大量复杂面数据做频繁分析。

Q6：重启内核后为什么变量都没了？

Kernel 是执行 Python 代码的进程。重启内核会清空内存中的变量、导入状态和临时对象。这是正常现象。重要中间结果应及时写入文件或数据库。

Q7：是否应该直接重装 Anaconda？

不建议一上来重装。先确认内核路径、依赖导入和数据读取。如果确实是环境混装导致 GDAL、Rasterio、GeoPandas 冲突，优先新建一个干净的 conda-forge 环境，而不是重装整个 Anaconda。

Q8：JupyterLab 和 Jupyter Notebook 哪个更适合 GIS？

两者都可以。关键不是界面，而是内核环境是否正确、GIS 依赖是否稳定、数据处理方式是否合理。对于新项目，JupyterLab 的文件管理和多标签体验更好；对于课程材料，经典 Notebook 仍然很常见。

结论：先定位链路，再修复环境，不要盲目重装

Jupyter Notebook运行代码无反应并不是一个单一错误。对 GIS 用户来说，最常见原因包括内核选错、Conda 环境冲突、GDAL 相关依赖不一致、ArcPy 环境不匹配、空间数据过大、文件路径异常和内存不足。

最稳妥的处理顺序是：先运行最小代码确认内核，再检查 sys.executable，然后逐个导入 GIS 库，接着用小数据测试读取，最后再运行完整空间分析流程。这样可以把问题快速缩小到浏览器、Jupyter Server、Python Kernel、GIS 依赖库或空间数据中的某一层。

如果你正在搭建新的 GIS 学习环境，建议使用独立 Conda 环境、统一 conda-forge 安装来源、明确注册 Jupyter 内核，并把 ArcPy 环境和 GeoPandas/Rasterio 环境分开维护。这样后续做坐标转换、空间连接、栅格处理和 WebGIS 数据预处理时，Notebook 的稳定性会高很多。