1. 为什么我三年前就停用 pip+virtualenv，转而把 Conda 当成 Python 环境的“操作系统”

你有没有过这种经历：在本地跑通的 Jupyter Notebook，发给同事后对方一打开就报ModuleNotFoundError: No module named 'pandas'；或者明明装了scikit-learn==1.3.0，运行时却提示AttributeError: module 'sklearn' has no attribute 'Pipeline'；又或者刚升级完numpy，整个matplotlib图形渲染直接崩掉，连 import 都失败——不是代码错了，是环境乱了。

这不是你手残，是传统 Python 环境管理工具在底层逻辑上就存在结构性缺陷。pip 是包安装器，virtualenv 是环境隔离器，二者拼凑使用，本质是“打补丁式协作”：pip 不管二进制兼容性，virtualenv 不管依赖冲突，它们共同默认一个危险假设——“所有包都能在同一个 Python 解释器里和平共处”。现实呢？numba要求特定版本的 LLVM 运行时，pytorch的 CUDA 版本必须和cudnn、驱动、nvidia-smi输出严格对齐，opencv-python-headless和opencv-contrib-python甚至会因 ABI 符号冲突导致 segfault。这些根本不是“装错包”的问题，而是编译时链接、运行时加载、ABI 兼容性、二进制分发形态等系统级问题。

Conda 不是 pip 的增强版，它是从零设计的跨语言包与环境管理系统。它不依赖 PyPI，自有 conda-forge、anaconda.org 等二进制仓库；它不只装 Python 包，还能装ffmpeg、openblas、rust-toolchain、nodejs；它做依赖解析时，不是比对setup.py里的install_requires字符串，而是读取每个包元数据中声明的build: number、run_constrained、track_features等字段，构建完整的有向无环图（DAG），再用 SAT 求解器找出满足所有约束的唯一解。这解释了为什么conda install pytorch torchvision cpuonly -c pytorch一条命令就能同时拉取匹配的pytorch-2.3.1-py311_cpu_0.tar.bz2、torchvision-0.18.1-py311_cpu_0.tar.bz2、libtorch-2.3.1-hd5a744e_0.tar.bz2、openblas-0.3.26-hb979f0a_0.tar.bz2——它们在构建时就被打上了同一套哈希签名，确保 ABI 层面完全兼容。

Jupyter 不是 Conda 的附属品，但它是 Conda 生态最自然的交互界面。当你用conda activate myenv切换环境后，jupyter kernelspec list显示的 kernel 名称自动带环境标识，jupyter notebook启动时默认加载该环境的 Python 解释器和全部已安装包，无需手动注册 kernel、不用改sys.path、不需!pip install --user。这不是便利性优化，而是环境状态与计算上下文的强绑定——你在哪个环境里写代码，就在哪个环境里执行，没有歧义，没有幻觉。

所以这篇教程不叫“Conda 和 Jupyter 怎么装”，它叫“如何用 Conda 把 Jupyter 变成你 Python 工作流的确定性入口”。接下来每一节，都对应一个真实踩坑现场：不是教你怎么点按钮，而是告诉你为什么这个按钮必须这么按，以及不这么按时，你的内存、磁盘、时间、项目交付周期会付出什么代价。

2. 初始化：避开 conda init 的三大认知陷阱与 root 环境毒化风险

很多人第一次装 Miniconda 后，第一反应是执行conda init bash（或zsh），然后重启终端。结果发现 shell 提示符变了，多了(base)前缀，更糟的是，which python指向了~/miniconda3/bin/python，而pip list里赫然出现jupyter,ipykernel,numpy……你还没建任何环境，base就已经是个“半成品项目环境”了。这是 Conda 设计者埋下的第一个温柔陷阱。

2.1 陷阱一：base环境不是“系统环境”，而是“管理员环境”

base是 Conda 安装时创建的初始环境，它包含conda自身及其依赖（python,openssl,curl,sqlite等）。它的定位是Conda 工具链的运行载体，不是你写数据分析代码的地方。官方文档明确建议：“Never install packages into the base environment for day-to-day work.”（切勿在 base 环境中为日常开发安装包）。原因有三：

• 升级风险不可控：conda update conda会更新base中的python。某次conda update后，base的 Python 从 3.11 升到 3.12，而你所有基于 3.11 编译的 C 扩展（如numba,llvmlite）全部失效，import numba直接ImportError: DLL load failed。修复方式不是重装 numba，而是降级 Python，而这又可能破坏 conda 自身。
• 污染传播链：一旦你在base中conda install jupyter，jupyter kernelspec list就会注册一个名为python3的 kernel，指向base的 Python。当你新建 notebook 时，默认选的就是它。更隐蔽的是，jupyter的--allow-root模式下，它甚至会把base的 kernel 写入系统级/usr/local/share/jupyter/kernels/，导致所有用户共享这个不稳定内核。
• 空间黑洞：base环境会随你不断conda install积累大量未被引用的包缓存。conda clean --all能清下载包，但无法清理base中因依赖传递安装的冗余包（如jupyter依赖tornado，tornado依赖certifi，certifi又被requests依赖——删tornado会连带删certifi，导致requests失效）。实测某位开发者base环境膨胀至 12GB，其中 7GB 是重复的pyarrow、pandas多版本 tar.bz2 文件。

提示：初始化后立即执行conda config --set auto_activate_base false，并重启终端。此后conda activate默认不激活base，终端启动时干净清爽，which python指向系统 Python，彻底切断base对日常工作的干扰。

2.2 陷阱二：conda init修改 shell 配置的本质是“劫持 PATH”

conda init bash的核心动作，是在~/.bashrc末尾追加一段脚本：

# >>> conda initialize >>> # ... 省略注释 ... # >>> conda initialize >>> # ... 省略 conda.sh 加载逻辑 ...

这段脚本的作用，是把~/miniconda3/bin插入PATH最前面。这带来两个隐藏问题：

• Shell 启动变慢：每次新开终端，shell 都要遍历~/miniconda3/bin下数百个可执行文件（conda,python,pip,jupyter,curl,tar,gzip……），检查其file类型和ldd依赖。在机械硬盘或 NFS 挂载目录下，这个过程可长达 1–2 秒。某高校 HPC 集群用户反馈，启用 conda init 后，SSH 登录延迟从 0.3 秒升至 1.8 秒，原因是PATH中~/miniconda3/bin触发了远程文件系统多次 stat 调用。
• 与系统管理冲突：企业 IT 部门常通过PATH管理策略强制指定python3指向/usr/bin/python3.9（经安全加固版本）。conda init的硬插入会覆盖此策略，导致合规审计失败。正确做法是：不运行conda init，改为手动在~/.bashrc中添加export PATH="~/miniconda3/bin:$PATH"，并在其上方加注释# Conda PATH injection - managed by DevOps，便于审计追踪。

2.3 陷阱三：jupyter notebook启动时的隐式环境绑定

当你未激活任何 conda 环境，直接运行jupyter notebook，它会 fallback 到PATH中第一个python（通常是base的）。此时 notebook 页面右上角显示的 kernel 名是Python 3，但实际执行环境是base。更危险的是，如果你之前在base中装过tensorflow，而当前项目需要pytorch，你在 notebook 里import torch失败，第一反应是“是不是没装 torch？”，于是!pip install torch——结果pip把 torch 装进了base，污染了管理员环境。

解决方案是：永远用显式环境启动 Jupyter。流程必须是：

1. conda create -n myproject python=3.11（创建干净环境）
2. conda activate myproject（激活）
3. conda install jupyter ipykernel（在该环境装 Jupyter 核心组件）
4. python -m ipykernel install --user --name myproject --display-name "Python (myproject)"（注册 kernel）
5. jupyter notebook（启动）

注意第 4 步的--user参数：它把 kernel spec 写入~/.local/share/jupyter/kernels/myproject/，而非系统级路径，确保权限隔离。--name是 kernel 的内部 ID（用于命令行切换），--display-name是 notebook 界面中显示的名称，二者可不同，但强烈建议保持一致，避免混淆。

3. 环境构建：从environment.yml到可复现的科研计算环境

在数据科学团队中，最常听到的抱怨是：“我在本地跑得好好的，CI 流水线却一直 fail”。根源往往不是代码 bug，而是环境不可复现。requirements.txt只能锁定 pip 包版本，对glibc版本、CUDA驱动、OpenMP运行时、libgfortranABI 等底层依赖束手无策。Conda 的environment.yml是目前唯一能描述完整计算栈的文本协议。

3.1environment.yml的四层结构：为什么不能只写dependencies

一个健壮的environment.yml必须包含四个关键区块：

# environment.yml name: ml-research-v2 channels: - conda-forge - pytorch - defaults dependencies: - python=3.11 - numpy=1.26.4 - pandas=2.2.2 - pytorch=2.3.1=py311_cpu_0 - torchvision=0.18.1=py311_cpu_0 - jupyter=1.0.0 - ipykernel=6.29.5 - pip - pip: - transformers==4.41.2 - datasets==2.19.1 prefix: /home/user/miniconda3/envs/ml-research-v2

• channels顺序即解析优先级：Conda 按列表顺序搜索包。conda-forge是社区最活跃的仓库，包更新最快；pytorch是官方渠道，保证 CUDA 版本精准匹配；defaults是 Anaconda 官方源，稳定性高但更新慢。把conda-forge放第一位，能获取最新修复，但需警惕其某些包（如r-base）与defaults的 ABI 冲突。实测某生物信息 pipeline 因conda-forge的htslib与defaults的samtools链接不同zlib版本，导致samtools view读取.bam文件时 core dump。解决方案：统一使用conda-forge，或在environment.yml中显式指定htslib=1.19=ha89122a_1（来自defaults）。

• dependencies中的=语法是 ABI 锁定的关键：pytorch=2.3.1=py311_cpu_0中的py311_cpu_0是 build string，它编码了编译时的所有关键参数：py311表示 Python 3.11，cpu表示 CPU-only 构建，0是构建序号。这个字符串确保你拉取的包与torchvision=0.18.1=py311_cpu_0使用完全相同的编译器、链接器、运行时库。如果只写pytorch=2.3.1，Conda 可能选py311_cuda12.1_0（GPU 版），在无 GPU 机器上直接失败。

• pip块是必要的“最后一公里”：Conda 仓库尚未覆盖所有 PyPI 包。pip块允许你在 conda 环境中安装 pip-only 包，但必须放在dependencies底部，并用- pip:显式声明。否则 Conda 会尝试用 conda 解析 pip 包，导致ResolvePackageNotFound错误。更重要的是，pip install在 conda 环境中默认使用--no-deps，即不安装依赖，因此transformers的依赖（如tokenizers,safetensors）必须由 conda 或 pip 显式列出，否则 runtime import 失败。

• prefix字段是环境路径的绝对声明：它让conda env create -f environment.yml创建的环境固定在指定路径，而非默认的~/miniconda3/envs/<name>。这对 HPC 集群至关重要：用户主目录常挂载在 NFS 上，I/O 性能差，而/scratch分区是本地 SSD。设置prefix: /scratch/user/ml-env，可将整个环境（含所有.so文件）放在高速存储上，import torch速度提升 3–5 倍。

3.2 生成可复现environment.yml的黄金三步法

不要手写environment.yml，用 Conda 自带工具生成：

1. 在目标环境中运行conda env export：

   conda activate myproject conda env export --from-history > environment.yml

   --from-history是关键：它只导出你conda install显式安装的包，忽略 Conda 自动安装的依赖（如python,openssl）。这样生成的文件更简洁，且conda env create重建时会重新解析依赖，确保 ABI 兼容性。

2. 人工精简与加固：

   • 删除prefix行（避免路径硬编码）
   • 将pip包从dependencies中剥离，单独写入pip块
   • 替换模糊版本为精确 build string（如numpy=1.26.4=py311h1e22a9d_0→ 查conda search numpy=1.26.4 --info获取）

3. 验证可复现性：

   # 清空原环境 conda env remove -n myproject # 用新 yml 重建 conda env create -f environment.yml conda activate myproject # 运行测试脚本 python -c "import torch; print(torch.__version__)"

某实验室曾用此法将一个深度学习训练环境从“每次重装都要调试 2 小时”缩短到“5 分钟全自动重建”，关键就是environment.yml中pytorch和cudatoolkit的 build string 完全匹配。

4. Jupyter Kernel 管理：从 “Python 3” 到精准环境映射的实战控制

Jupyter 的 kernel 机制常被误解为“只是换个 Python 解释器”。实际上，kernel 是一个独立进程，它通过 ZeroMQ 协议与 notebook 前端通信，其启动配置（kernel.json）决定了整个计算上下文。Conda 环境与 kernel 的映射，是 Jupyter 稳定性的基石。

4.1kernel.json文件结构解析：每个字段都是控制开关

当你执行python -m ipykernel install --user --name myenv --display-name "My Env"，Conda 在~/.local/share/jupyter/kernels/myenv/kernel.json创建如下文件：

{ "argv": [ "/home/user/miniconda3/envs/myenv/bin/python", "-m", "ipykernel_launcher", "-f", "{connection_file}" ], "display_name": "My Env", "language": "python", "metadata": { "debugger": true } }

• argv[0]是环境确定性的锚点：它必须是 conda 环境中python的绝对路径。如果写成python（不带路径），kernel 启动时会依赖PATH，而PATH可能被 notebook 前端修改（如jupyter lab的--notebook-dir参数会 prepending 新路径），导致意外加载错误 Python。实测某 CI 环境因argv[0]为python，kernel 加载了系统 Python 3.9，而myenv是 3.11，import numpy报undefined symbol: PyUnicode_AsUTF8AndSize（ABI 不兼容）。

• {connection_file}是动态占位符，不可硬编码：Jupyter 启动 kernel 时，会生成一个临时 JSON 文件（含 TCP 端口、密钥等），并将路径传给argv。{connection_file}会被自动替换。若手动改成固定路径（如/tmp/connection.json），多个 notebook 实例会竞争写入，导致 kernel 启动失败或连接超时。

• "debugger": true开启 JupyterLab 调试器：这是 JupyterLab 4.x+ 的新特性，允许在 notebook 单元格中设断点、单步执行。但需注意：调试器依赖debugpy包，必须在 kernel 环境中安装。conda install debugpy后，kernel.json会自动添加此字段；若缺失，调试器图标灰显。

4.2 多环境 kernel 冲突排查：当 “Python (myenv)” 突然变成 “Python 3”

现象：你在myenv中注册了 kernel，notebook 界面显示 “Python (myenv)”，但点击后单元格执行!which python却输出/usr/bin/python3。这不是 UI bug，是 kernel 启动时argv[0]被覆盖。

排查链路：

1. 确认 kernel 注册路径：jupyter kernelspec list输出类似：

   Available kernels: myenv /home/user/.local/share/jupyter/kernels/myenv python3 /usr/local/share/jupyter/kernels/python3

   如果myenv路径指向/usr/local/share/...，说明注册时漏了--user，kernel 被写入系统级目录，可能被 IT 策略覆盖。

2. 检查kernel.json的argv[0]：

   cat ~/.local/share/jupyter/kernels/myenv/kernel.json | jq '.argv[0]'

   输出应为"/home/user/miniconda3/envs/myenv/bin/python"。若为"python"，则需手动编辑修复。

3. 验证 Python 解释器是否真属该环境：

   /home/user/miniconda3/envs/myenv/bin/python -c "import sys; print(sys.executable); import numpy; print(numpy.__version__)"

   若报ModuleNotFoundError，说明myenv中未装numpy，或PYTHONPATH被污染。

4. 终极诊断：启动 kernel 并查看日志：

   jupyter notebook --debug 2>&1 | grep -A5 -B5 "Starting kernel"

   日志中会显示 kernel 启动命令及返回码。若出现OSError: [Errno 2] No such file or directory，说明argv[0]路径不存在（环境被删除或重命名）。

注意：jupyter kernelspec remove myenv删除 kernel 后，不会删除 conda 环境，但conda env remove -n myenv会删除环境，其 kernel 自动失效（jupyter kernelspec list中仍显示，但点击时报 “Kernel not found”）。务必先jupyter kernelspec remove，再conda env remove，避免残留。

4.3 动态 kernel 切换：用nb_conda_kernels实现环境感知

手动注册 kernel 适合项目环境，但对快速实验（如试不同 Python 版本）效率低。nb_conda_kernels扩展可自动扫描所有 conda 环境，并为每个含ipykernel的环境生成 kernel。

安装与启用：

conda activate base conda install nb_conda_kernels jupyter server extension enable --py nb_conda_kernels

启用后，jupyter notebook启动时会自动发现~/miniconda3/envs/py39,~/miniconda3/envs/py311,~/miniconda3/envs/tf2等所有环境，并在 kernel 列表中显示为 “Python (py39)”、“Python (py311)”、“Python (tf2)”。其原理是：nb_conda_kernels在jupyter_server_config.py中注册了一个CondaKernelSpecManager，它定期调用conda env list --json获取环境列表，再对每个环境执行conda run -n <env> python -m ipykernel install --user --name <env> --display-name "Python (<env>)"。

优势：环境增删自动同步，无需手动kernelspec install/remove。
风险：若某环境ipykernel损坏（如pip uninstall ipykernel），nb_conda_kernels会尝试注册失败 kernel，导致 notebook 启动时卡在 “Connecting to kernel…”。此时需conda activate <env> && conda install ipykernel修复。

5. 高级场景：离线部署、HPC 集群与 JupyterHub 的 Conda 环境治理

在生产环境，Conda 的价值远超个人开发。它解决了科研计算中最棘手的“最后一公里”问题：如何让复杂软件栈在无外网、无 root 权限、异构硬件的环境中稳定运行。

5.1 离线环境打包：conda-pack的原子化交付

某国家级气象中心要求所有模型代码在内网服务器运行，服务器无法访问互联网。传统方案是pip download+pip install --find-links，但无法解决pytorch的 CUDA 二进制依赖。conda-pack是 Conda 官方提供的离线打包工具，它将整个 conda 环境（含所有.so,.dll,bin/可执行文件）打包为 tar.gz，并重写所有 RPATH，确保解压后可直接运行。

操作流程：

# 在联网机器上 conda activate mymodel conda install conda-pack conda-pack -n mymodel -o mymodel.tar.gz # 在离线服务器上 mkdir -p /opt/mymodel tar -xzf mymodel.tar.gz -C /opt/mymodel # 激活环境（无需 conda） source /opt/mymodel/bin/activate # 验证 python -c "import torch; print(torch.cuda.is_available())" # False，因无 GPU

conda-pack的核心能力是--strip和--ignore-editable：

• --strip：移除调试符号（.debug段），减小包体积 30–50%。某遥感处理环境从 8.2GB 压缩至 5.7GB。
• --ignore-editable：跳过pip install -e .的开发模式包，避免打包源码目录（可能含.git、大测试数据）。

提示：conda-pack打包的环境是“自包含”的，但jupyterkernel 仍需手动注册。离线服务器上执行：

source /opt/mymodel/bin/activate python -m ipykernel install --user --name mymodel --display-name "Mymodel (Offline)"

5.2 HPC 集群上的 Conda 环境共享：conda constructor构建定制发行版

大学超算中心常面临矛盾：用户需要pytorch，但集群登录节点禁止安装大型包（磁盘配额 5GB）；计算节点有 GPU，但用户无权限sudo apt install cuda-toolkit。conda constructor可将environment.yml编译为自解压安装包（.sh），管理员可预装到/shared/conda/，用户一键安装到个人目录。

构建步骤：

# 准备构造配置 cat > constructor.yaml << EOF name: hpc-data-science version: 1.0 channels: - conda-forge - pytorch specs: - python=3.11 - pytorch=2.3.1=py311_cuda12.1_0 - cudatoolkit=12.1.1=h2bc3f7f_2 - jupyterlab=4.0.11 - dask=2024.5.0 EOF # 构建安装包 constructor constructor.yaml # 生成 hpc-data-science-1.0-Linux-x86_64.sh

用户使用：

# 下载安装包到个人目录 wget https://hpc-center.edu/conda/hpc-data-science-1.0-Linux-x86_64.sh bash hpc-data-science-1.0-Linux-x86_64.sh -b -p $HOME/miniconda3-hpc # 激活 source $HOME/miniconda3-hpc/bin/activate

constructor的优势在于：它不依赖conda运行时，安装包内含精简版conda（constructor自带），即使集群无 conda，也能安装。某天文台用此法将astropy+healpy+mpi4py环境分发给 200+ 研究生，安装时间从平均 47 分钟降至 90 秒。

5.3 JupyterHub 中的 Conda 环境隔离：wrapspawner与conda-store

在多用户 JupyterHub（如学校教学平台），需确保 A 学生的tensorflow环境不影响 B 学生的pytorch环境。wrapspawner是轻量方案：它在用户 spawn notebook 前，执行conda activate student-a，将 kernel 绑定到指定环境。

但更健壮的方案是conda-store：它是一个独立服务，提供 REST API 管理 conda 环境，并与 JupyterHub 集成。教师上传environment.yml，conda-store自动构建环境镜像（OCI 格式），JupyterHub 调用时拉取对应镜像启动容器。环境构建日志、依赖图谱、安全扫描（CVE 检查）全部可审计。

某在线教育平台采用conda-store后，学生环境创建失败率从 12% 降至 0.3%，平均创建时间从 3.2 分钟降至 22 秒，因为conda-store的构建缓存可复用numpy,pandas等基础层镜像。

6. 故障排除：从 “Kernel Starting” 卡死到 “ImportError” 的全链路诊断

Jupyter 启动失败的错误信息常高度误导。Kernel starting卡住，90% 的情况不是网络问题，而是 kernel 进程启动后立即崩溃，Jupyter 前端收不到连接确认。以下是按发生频率排序的五大故障及其诊断路径。

6.1 故障一：OSError: [Errno 2] No such file or directory——argv[0]路径失效

现象：点击 kernel 后，notebook 右上角显示 “Kernel starting…”，数秒后变为 “Kernel error”，控制台无日志。

诊断：

# 查看 kernel.json jupyter kernelspec list cat ~/.local/share/jupyter/kernels/myenv/kernel.json | jq '.argv[0]' # 检查路径是否存在 ls -l /home/user/miniconda3/envs/myenv/bin/python

根因：conda env remove -n myenv删除了环境，但kernelspec未清理。argv[0]指向已删除路径。

修复：

jupyter kernelspec remove myenv conda activate base conda env create -f environment.yml # 重建环境 conda activate myenv python -m ipykernel install --user --name myenv --display-name "My Env"

6.2 故障二：ImportError: libxxx.so: cannot open shared object file—— RPATH 断裂

现象：kernel 启动成功（显示 “Connected”），但执行import torch报libnvrtc.so.12: cannot open shared object file。

诊断：

# 在 kernel 环境中检查依赖 conda activate myenv ldd $(which python) | grep "not found" # 检查 torch 的 so 依赖 ldd $CONDA_PREFIX/lib/python3.11/site-packages/torch/lib/libtorch.so | grep "not found"

根因：libnvrtc.so.12是 CUDA 运行时库，应由cudatoolkit包提供。但cudatoolkit的post-link.sh脚本未执行，或LD_LIBRARY_PATH未包含$CONDA_PREFIX/lib。

修复：

# 强制运行 post-link conda activate myenv $CONDA_PREFIX/etc/conda/activate.d/activate-gcc.sh # 或手动添加 LD_LIBRARY_PATH echo 'export LD_LIBRARY_PATH="$CONDA_PREFIX/lib:$LD_LIBRARY_PATH"' >> $CONDA_PREFIX/etc/conda/activate.d/env_vars.sh

6.3 故障三：Connection failed—— ZeroMQ 端口被占用

现象：kernel 显示 “Connected”，但单元格执行无响应，控制台报Connection failed: [Errno 111] Connection refused。

诊断：

# 查看 Jupyter 启动时分配的端口 jupyter notebook --debug 2>&1 | grep "Starting kernel" # 输出类似：Starting kernel: ['/home/.../python', '-m', 'ipykernel_launcher', '-f', '/run/user/1000/jupyter/kernel-12345.json'] # 检查该 JSON 文件内容 cat /run/user/1000/jupyter/kernel-12345.json | jq '.ip, .shell_port, .iopub_port' # 检查端口是否被占用 ss -tuln | grep ":54321" # shell_port 示例

根因：jupyter启动时随机选择端口，若该端口被其他进程占用，kernel 进程会启动但无法绑定 socket，导致前端连接失败。

修复：

# 启动时指定端口范围 jupyter notebook --port-range 8888-8899 # 或在 ~/.jupyter/jupyter_notebook_config.py 中设置 c.NotebookApp.port_retries = 50

6.4 故障四：ModuleNotFoundError在!pip install后仍存在

现象：在 notebook 中执行!pip install requests，返回Successfully installed requests-2.31.0，但import requests仍报错。

诊断：

# 检查 pip 安装位置 !pip show requests # 输出：Location: /home/user/miniconda3/envs/myenv/lib/python3.11/site-packages # 检查 Python 的 site-packages !python -c "import site; print(site.getsitepackages())"

根因：!pip install调用的是 kernel 进程中的pip，但import语句由 kernel 的 Python 解释器执行。若pip和python不在同一环境（如pip是系统 pip，python是 conda python），则包装错地方。

修复：永远用!{sys.executable} -m pip install：

import sys !{sys.executable} -m pip install requests

sys.executable返回 kernel 的 Python 路径，确保pip和python同源。

6.5 故障五：Permission denied写入~/.local/share/jupyter/kernels/

现象：python -m ipykernel install --user报PermissionError: [Errno 13] Permission denied: '/home/user/.local/share/jupyter/kernels'。

根因：~/.local/share目录权限被 IT 策略设为700，但jupyter创建子目录