
Ubuntu 22.04 LTS 这套系统我前前后后装过十几遍从 VMware 里的练手机到后来跑在物理机和 ESXi 上的数据分析机每次配环境都要重新走一遍“装 Anaconda、起 Jupyter Notebook”的流程。标题里这件事看着简单但真上手就会发现坑不少conda 命令找不到、Jupyter 打不开、单元格执行半天没反应、换源之后反而更慢。这篇就把 ubuntu 22.04 系统下搭建 anaconda 环境并安装 jupyter notebook 的整条链路拆开讲从系统核查、依赖补齐、Anaconda 安装、conda 换源、虚拟环境管理一直到 Jupyter 的配置、远程访问和故障排查。刚接触 Linux 的新手能照着抄作业已经用过一段时间的朋友也能从排查思路和参数细节里捡到点东西。1. 方案整体设计与选型思路1.1 为什么是 Anaconda 而不是系统 Python 加 pip 加 venvUbuntu 22.04 自带 Python 3.10理论上 pip 加 venv 就能干活但做数据分析、机器学习这类场景Anaconda 省下来的时间是真金白银。原因有几个层面。第一是二进制包的问题。科学计算栈里的 numpy、scipy、pandas、pytorch 这些库很多底层依赖 BLAS、LAPACK、MKL 这类数学库用 pip 装的时候经常要现场编译编译失败报错一长串新手根本看不懂。conda 提供的是预编译好的二进制包解压即用不依赖系统里的 gcc 版本也不容易和系统库打架。第二是环境隔离的粒度。venv 只隔离 Python 包conda 连 Python 解释器本身、编译器、CUDA 工具链都能隔离。同一台机器上跑一个 Python 3.9 加 torch 1.x 的老项目再跑一个 Python 3.11 加新版框架的项目用 conda 切环境一句话搞定互不干扰。第三是依赖求解器。conda 的 SAT 求解器在处理复杂依赖关系时比 pip 更保守虽然偶尔慢但基本不会出现装完之后环境半死不活的情况。pip 那种“装到一半发现版本冲突然后整个环境报废”的经历踩过一次就再也不想踩了。提示Anaconda 的 base 环境不要拿来当主力开发环境官方也不建议。base 装的东西越少越稳真正的项目都放独立环境里。1.2 为什么把开发环境放在 Ubuntu 22.04 上选 Ubuntu 22.04 LTS 而不是更新的版本核心原因是稳定性窗口。LTS 版本官方支持到 2027 年期间软件源里的包版本相对固定不会出现今天能跑的脚本下个月因为系统库升级就崩掉的情况。22.04 相比 20.04内核升到了 5.15对新一代硬件的兼容性好了不少尤其是显卡驱动和网卡这块装 NVIDIA 驱动的成功率明显提升。另一个现实原因是生态资料多。出问题的时候随便搜一个报错信息基本都能找到在 22.04 上的解决方案。这点对新手特别重要环境搭不起来的时候能不能快速定位问题直接决定了你还有没有耐心继续学下去。至于有人纠结的 WSL、虚拟机还是物理机我的建议是学习阶段用 WSL 或 VMware 虚拟机都行WSL 启动快、和宿主机文件互通方便要做长时间训练或者对 IO 性能敏感还是物理机或者 ESXi 上的独占虚拟机更靠谱。三者的 Anaconda 安装流程基本一致差别主要在磁盘挂载和显卡直通上。1.3 整体部署路径拆解把整件事拆开其实是六个阶段递进的关系系统层核查确认版本、架构、磁盘空间、内存补齐基础编译工具。Anaconda 落地下载安装包、校验完整性、静默安装、初始化 shell。包管理加速配置 conda 和 pip 的国内镜像源解决下载慢的问题。虚拟环境构建创建独立环境安装科学计算栈和项目依赖。Jupyter 部署安装 Notebook、注册内核、写配置文件、设置密码。访问与常驻本地访问或远程访问后台运行开机自启。这个顺序不能乱。先把 shell 环境搞对后面 conda 命令才认先配好源装包才不会卡在下载上先有干净的环境再装 Jupyter内核注册才不会串到 base 里去。我见过不少人一上来就装 Jupyter装完发现内核列表里一堆乱七八糟的环境最后自己都分不清哪个对应哪个。2. Ubuntu 22.04 基础环境准备2.1 装之前先核对版本、架构、磁盘和内存动手之前先花两分钟做个体检能省掉后面一堆莫名其妙的报错。第一条命令看系统版本lsb_release -a cat /etc/os-release输出里要能看到Ubuntu 22.04.x LTS。如果显示的是 20.04 或者 24.04那后面下载安装包的时候架构和依赖可能有差异得注意。第二条看 CPU 架构uname -mx86_64是常见的 Intel/AMD 平台直接下标准安装包如果是aarch64那就是 ARM 平台比如某些云服务器必须下对应的 ARM 版本安装包装错了会直接报“无法执行二进制文件”这种让人一头雾水的错误。第三条看磁盘和内存df -h free -hAnaconda 完整安装大概占 5 到 8 GBconda 包缓存目录 pkgs 用得久了能膨胀到十几 GB 甚至几十 GB。根分区至少留 20 GB 富余空间不然装到一半提示空间不足清理起来很麻烦。内存建议 8 GB 以上跑 Jupyter 加 pandas 处理中等规模数据4 GB 会经常触发 OOM内核被系统杀掉表现就是单元格执行着执行着突然没反应了。2.2 补齐基础工具链与编译依赖Ubuntu 22.04 的最小化安装版本很多基础工具是缺的。第一步先更新软件源索引sudo apt update sudo apt upgrade -y然后装一批常用工具sudo apt install -y build-essential wget curl git vim \ bzip2 ca-certificates libgl1-mesa-glx libegl1-mesa \ libxrandr2 libxss1 libxcursor1 libxi6 libxtst6 libglib2.0-0这里解释几个容易被忽略的包。build-essential包含了 gcc、g、make有些 pip 包没有预编译 wheel要现场编译缺了它直接报错。bzip2是解压部分 conda 包用的虽然现代 Anaconda 安装包是 .sh 自解压格式但后续 conda 安装某些包时仍可能用到。后面那串libgl开头的图形库是 Jupyter 里做可视化或者跑某些深度学习库时依赖的缺了会报libGL.so.1: cannot open shared object file这个错误在服务器上装了 OpenCV 之后特别常见。注意如果你用的是最小化安装的服务器版 Ubuntu没有图形界面上面那串 lib 里有一部分装了也没坏处但不要尝试去装完整的桌面环境几百 MB 的依赖会把服务器搞得又慢又乱。2.3 外围环境中文输入法、SSH、字体这些小事先办还是后办这个问题我纠结过结论是跟主线无关的外围配置放到主线跑通之后再折腾。原因很简单中文输入法和 Anaconda 安装没有任何依赖关系但如果先装输入法中途要重启、要改环境变量反而干扰主线排查。一旦 Jupyter 出问题你会怀疑是不是输入法动了什么配置。不过有两件事建议提前确认。第一是 SSH 能不能连上。如果你是在 ESXi 或云服务器上操作SSH 不通就没法干活。检查一下服务状态sudo systemctl status ssh sudo ss -ltnp | grep :22如果服务没起来sudo systemctl enable --now ssh拉起来。如果服务在但连不上多半是防火墙规则或者云服务商的安全组没放行 22 端口这个跟系统本身无关。第二是终端字体和显示体验。长时间盯着终端和 Jupyter 界面写代码字体选得不好眼睛是真的累。Ubuntu 默认的等宽字体其实还行但如果你从其他系统迁移过来觉得不顺手可以装一款 Nerd Font 系列的等宽字体在终端设置里换掉。注意别选那种带连字的编程字体配旧版终端容易出现字符错位。这个属于锦上添花不影响功能完全可以放到最后再调。3. Anaconda 安装实操全流程3.1 安装包获取与完整性校验Anaconda 的官网在国内访问速度不稳定我的习惯是走国内高校的开源镜像站下载。这样做的好处是速度快而且镜像站通常会同步官方校验值方便核对。先建一个临时目录把安装包下到这里mkdir -p ~/downloads cd ~/downloads wget https://mirrors.tuna.tsinghua.edu.cn/anaconda/archive/Anaconda3-2024.10-1-Linux-x86_64.sh文件名里的版本号会随时间更新去镜像站的 archive 目录看一眼最新的就行。下载完之后一定要校验这一步很多人跳过但一旦安装包下载不完整安装过程会在解压阶段报一堆看不懂的错误sha256sum Anaconda3-2024.10-1-Linux-x86_64.sh拿输出的哈希值去镜像站或者官方页面核对一致才能继续。这一步花十秒钟能避免后面半小时的瞎折腾。3.2 静默安装与安装路径选择Anaconda 的安装脚本支持交互式安装但服务器环境或者自动化脚本里用静默安装更省事bash Anaconda3-2024.10-1-Linux-x86_64.sh -b -p $HOME/anaconda3-b是 batch 模式全程不问问题-p指定安装路径。路径的选择有个讲究装在$HOME/anaconda3下好处是普通用户就有写权限后续 conda 装包、更新都不需要 sudo避免了 root 装完之后普通用户用不了的经典问题。装到/opt或者/usr/local下多用户共享方便但权限管理麻烦还要处理不同用户的 shell 配置。我一般推荐单用户装在 home 目录下。如果你确实需要多用户共享装到/opt/anaconda3然后用 root 执行安装装完之后给每个用户的 shell 单独做初始化不要直接改系统级的/etc/profile容易污染所有用户的环境。安装脚本跑完最后会问要不要初始化 conda静默模式下这个默认是关的需要手动补上这一步。3.3 conda init 与 shell 配置到底改了什么初始化这一步非常关键也是“conda: command not found”这个经典报错的根源。执行$HOME/anaconda3/bin/conda init bash如果你用的是 zsh就把 bash 换成 zsh。执行完之后conda init会在~/.bashrc末尾插入一段标记好的代码块大概长这样# conda initialize # !! Contents within this block are managed by conda init !! __conda_setup$(/home/yourname/anaconda3/bin/conda shell.bash hook 2 /dev/null) if [ $? -eq 0 ]; then eval $__conda_setup else if [ -f /home/yourname/anaconda3/etc/profile.d/conda.sh ]; then . /home/yourname/anaconda3/etc/profile.d/conda.sh else export PATH/home/yourname/anaconda3/bin:$PATH fi fi unset __conda_setup # conda initialize 这段东西干了三件事定义了一个condashell 函数、把 base 环境的 bin 目录塞进 PATH、设置了CONDA_DEFAULT_ENV等环境变量。关键点是它必须在 PATH 赋值语句之后执行。如果你自己之前手动在.bashrc里写过export PATH...而且顺序在 conda 初始化之后那 conda 的路径就会被覆盖掉导致命令又找不到了。改完配置让当前 shell 生效source ~/.bashrc conda --version能打印出版本号说明初始化成功。提示Ubuntu 22.04 里如果你用过 pyenv、nvm 这类工具它们也会改 PATH和 conda 初始化顺序冲突的概率很高。排查思路就是echo $PATH看看 anaconda3/bin 到底在第几位以及有没有被别的东西整体覆盖。3.4 conda 与 pip 双通道换源不换源的话conda 装包的速度会让人怀疑人生。换源要分两条通道conda 自己的源用.condarc配置pip 的源用pip.conf配置两者互不干涉。配置 conda 源cat ~/.condarc EOF channels: - defaults show_channel_urls: true default_channels: - https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/main - https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/r - https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/msys2 custom_channels: conda-forge: https://mirrors.tuna.tsinghua.edu.cn/anaconda/cloud pytorch: https://mirrors.tuna.tsinghua.edu.cn/anaconda/cloud EOFshow_channel_urls: true这一行很有用装包的时候能看到具体从哪个源下载的出问题好定位。custom_channels里把 conda-forge 和 pytorch 指向镜像装这些频道的包时速度会快很多。配置 pip 源mkdir -p ~/.pip cat ~/.pip/pip.conf EOF [global] index-url https://pypi.tuna.tsinghua.edu.cn/simple trusted-host pypi.tuna.tsinghua.edu.cn timeout 120 EOF清除 conda 的索引缓存让新配置立即生效conda clean -i这里有个经验教训不要迷信“换源一定快”。国内镜像站偶尔会有同步延迟某个包的新版本在镜像上还没更新装的时候会提示找不到。遇到这种情况临时加上-c conda-forge或者用--override-channels指定官方源装完再切回来。另外.condarc里如果同时写了很多源conda 求解依赖时会挨个查反而变慢源不是越多越好。4. 用 conda 管理虚拟环境与科学计算栈4.1 创建环境的参数选择与命名规范创建环境这个动作参数看着简单但选错 Python 版本后面全是麻烦conda create -n ds python3.10 -y命名上我建议带点信息量比如ds代表数据科学torch2代表 PyTorch 2.xnlp-exp代表自然语言实验。最忌讳的是test、env1、new这种名字过两周你自己都想不起来里面装了什么。Python 版本的选择有讲究。截至写这篇的时候3.10 和 3.11 的生态兼容性最好主流框架都跟上了。3.12 虽然新但有些小众库还没适配尤其是那种几年没更新的科研专用包装上去会直接报编译错误。如果你要跑深度学习的项目先去项目文档里确认推荐的 Python 版本别自己拍脑袋选。环境创建好之后激活conda activate ds python --version which pythonwhich python的输出应该指向~/anaconda3/envs/ds/bin/python。如果指向/usr/bin/python说明激活没生效检查前面 conda init 那步。退出环境用conda deactivate看当前有哪些环境用conda env list。删除环境用conda env remove -n ds注意这个动作不可恢复删之前确认里面没有重要的自定义代码。4.2 科学计算三件套与常用库安装环境建好装包。基础的几件套conda install numpy pandas matplotlib scipy scikit-learn -y需要深度学习框架的话PyTorch 建议按官方给出的命令装因为它要匹配 CUDA 版本conda install pytorch torchvision torchaudio pytorch-cuda12.1 -c pytorch -c nvidia -y这里解释一下 CUDA 版本怎么选。先看显卡驱动支持的 CUDA 上限nvidia-smi输出右上角会显示CUDA Version: 12.4之类的信息这代表当前驱动最高支持的 CUDA 运行时版本。你装的 PyTorch 对应的 CUDA 版本不能超过这个数否则会报CUDA driver version is insufficient。选低于等于这个版本的都行比如驱动支持 12.4你装 12.1 或者 11.8 都没问题框架会向下兼容。没有独显或者不需要 GPU 加速的话装 CPU 版本就行conda install pytorch torchvision torchaudio cpuonly -c pytorch -y装完之后验证一下import torch print(torch.__version__) print(torch.cuda.is_available())cuda.is_available()返回 True 说明 GPU 通路没问题返回 False 就得回头查驱动和 CUDA 版本匹配。注意conda 和 pip 混用要小心。装包优先用 condaconda 里没有的再用 pip而且同一个包不要一会儿用 conda 装一会儿用 pip 装会导致环境里出现两份不同来源的同名包排查起来非常痛苦。4.3 环境导出、迁移与复现项目跑通之后把环境导出成文件方便在别的机器上复现conda env export --no-builds environment.yml加上--no-builds是去掉具体的 build 号提高跨平台的兼容性。如果只想导出你手动装的包不想带上那一长串依赖用conda env list --json pip freeze requirements.txt新建环境时只需要conda env create -f environment.yml这里有个坑environment.yml里会包含prefix字段记录的是原机器上的环境路径。换机器之后这个字段会让 conda 试图装到不存在的路径直接报错。打开文件把最后那行prefix:删掉就行。另外一个现实问题导出的环境文件在跨操作系统时会失效Windows 导出的装到 Ubuntu 上大概率失败因为底层构建号完全不同。跨平台迁移的稳妥做法是记录 Python 版本加包列表在新平台上重新装一遍而不是直接套用环境文件。5. Jupyter Notebook 安装配置与远程访问5.1 安装与内核注册的完整链条在当前激活的环境里装 Jupyterconda install jupyter notebook -y装完之后立刻做一件事把当前环境注册成 Jupyter 的内核conda activate ds python -m ipykernel install --user --nameds --display-namePython (ds)这两个参数的区别要搞清楚。--name是内核的内部标识必须是唯一的重名会覆盖--display-name是在 Jupyter 界面上看到的名称随便起带空格带中文都行。建议 display-name 写得清楚一点比如Python (torch2-cuda121)以后在界面上选内核一眼就知道该选哪个。注册完之后查看已有的内核列表jupyter kernelspec list这个命令输出的路径也挺有用一般在~/.local/share/jupyter/kernels/下。需要删掉多余的内核就用jupyter kernelspec remove 内核名这里有个常见困惑为什么我在 base 环境装 Jupyter却能在里面跑其他环境的代码答案就是内核机制。Jupyter 本体和内核是两个独立的东西本体负责界面和通信内核负责执行代码。你只要把各个环境注册成内核一个 Jupyter 就能调度所有环境。反过来如果某个环境忘了注册内核在界面上就看不到它切换不过去。5.2 配置文件生成、密码哈希与关键参数先生成默认配置jupyter notebook --generate-config生成的配置文件路径一般在~/.jupyter/jupyter_notebook_config.py。这个文件里全是注释掉的配置项几百行直接改容易改错。我的做法是另建一个精简的配置文件或者在原文件末尾追加需要的项。设置访问密码jupyter notebook password按提示输入两次密码它会把哈希值写到~/.jupyter/jupyter_server_config.json里。不建议在配置文件里写明文密码也不要用passwd()手动生成哈希再粘贴容易因为引号转义问题出错。接下来是配置文件里最关键的几项。注意 Jupyter Notebook 7 及以上版本用的是ServerApp前缀旧版本用的是NotebookApp写错了配置不生效这个坑非常隐蔽# 新版 Notebook 7 用这些 c.ServerApp.ip 0.0.0.0 c.ServerApp.port 8888 c.ServerApp.open_browser False c.ServerApp.allow_remote_access True c.ServerApp.root_dir /home/yourname/notebooks c.ServerApp.allow_root False # 旧版沿用这些 # c.NotebookApp.ip 0.0.0.0 # c.NotebookApp.port 8888 # c.NotebookApp.open_browser False # c.NotebookApp.allow_remote_access Trueip设成0.0.0.0表示监听所有网卡这样才能远程访问只在本机用的话设127.0.0.1更安全。root_dir是工作目录设成专门建的一个目录别直接用 home 根目录否则界面上会列出一堆无关的隐藏配置文件。allow_root保持 False别用 root 身份跑 Jupyter既有安全风险某些包也会因为权限判断出问题。5.3 监听地址、端口与 SSH 端口转发访问配置好之后启动jupyter notebook启动日志会给一个带 token 的地址。如果你想让它后台跑nohup jupyter notebook ~/jupyter.log 21 查看日志确认是否正常起来了tail -f ~/jupyter.log访问方式分两种场景。第一种是局域网内直接访问浏览器输入http://服务器IP:8888输入之前设的密码就能进。前提是防火墙放行端口。Ubuntu 22.04 默认没开 ufw如果你开过需要sudo ufw allow 8888/tcp第二种更推荐走 SSH 端口转发不对外开放端口安全性高很多。在本机终端执行ssh -L 8888:127.0.0.1:8888 yourname服务器IP连上之后本地浏览器打开http://127.0.0.1:8888流量全部通过 SSH 加密隧道走服务器那边 Jupyter 只监听本地回环地址就行c.ServerApp.ip甚至可以设回127.0.0.1。这个方案在公网服务器上是最稳妥的把不必要的端口暴露面降到最低。注意0.0.0.0加无密码的组合等于把机器交出去。配置远程访问之前密码和 token 至少留一个两者都留最保险。5.4 后台常驻与开机自启用 nohup 挂着遇到系统重启就没了。要做成常驻服务用 systemd 更规范。新建服务文件sudo vim /etc/systemd/system/jupyter.service内容[Unit] DescriptionJupyter Notebook Service Afternetwork.target [Service] Typesimple Useryourname WorkingDirectory/home/yourname/notebooks ExecStart/home/yourname/anaconda3/envs/ds/bin/jupyter notebook --config/home/yourname/.jupyter/jupyter_notebook_config.py Restartalways RestartSec10 [Install] WantedBymulti-user.target几个细节要注意。User必须是拥有该 conda 环境的那个用户用 root 跑会在内核路径上出问题。ExecStart里用的 jupyter 要写绝对路径指向具体环境下的可执行文件因为 systemd 不走用户的 shell 初始化PATH 里没有 conda。WorkingDirectory和配置文件里的root_dir保持一致。启用并启动sudo systemctl daemon-reload sudo systemctl enable --now jupyter sudo systemctl status jupyter状态显示 active (running) 就成了。想改配置改完sudo systemctl restart jupyter。6. 高频故障排查实录6.1 conda 命令找不到的三层排查这是新手遇到频率最高的报错。排查顺序是自下而上的三层。第一层确认安装目录确实存在ls -d ~/anaconda3/bin/conda如果这个文件不存在说明安装那步就没成功回头看安装脚本的输出日志。第二层确认初始化有没有写进 shell 配置grep -n conda initialize ~/.bashrc没有输出就是没初始化补一句~/anaconda3/bin/conda init bash再source ~/.bashrc。第三层也是最容易忽略的确认 PATH 顺序没被覆盖echo $PATH | tr : \n | grep -n anaconda如果 anaconda3/bin 排在/usr/bin后面或者压根没出现就是被别的配置覆盖了。常见元凶是手动写的export PATH/usr/local/bin:$PATH排在 conda 初始化之后或者用了 pyenv、nvm 这类工具它们的初始化脚本把 PATH 整个重置了。解决办法是把 conda 初始化那段挪到.bashrc的最后一行或者在自己的 PATH 设置里显式包含 conda 路径。还有一种情况是登录方式和配置不匹配。比如你配的是.bashrc但用ssh userhost command这种非交互方式执行.bashrc根本不加载。这时候要么在命令里手动 source要么改用.profile配。6.2 单元格执行没反应、内核连不上代码敲进去按 ShiftEnter左上角显示[*]一直转圈半天没结果。这个问题的排查思路要分层。先看内核是不是真的起来了。在 Jupyter 界面的右上角会显示内核状态一个小圆点实心表示空闲空心表示忙碌。如果界面上的连接状态显示“已断开”或者一直在重连说明前端连不上内核进程。手动检查内核进程ps aux | grep ipykernel没有进程说明内核压根没启动多半是这个环境没注册到 Jupyter或者内核规格文件损坏。重新注册一遍内核通常能解决。有进程但连不上看资源占用。最常见的原因是内存不够内核被 OOM Killer 干掉了dmesg | grep -i killed process如果输出里能看到 python 进程被 kill 的记录那就是内存问题。解决办法有三条减小处理的数据量、给机器加内存、设置交换分区。加 swap 的临时方案sudo fallocate -l 4G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile想让重启后保留还得写进/etc/fstab。第三个原因是版本不匹配。Jupyter 本体和 ipykernel 的版本差异过大通信协议对不上表现就是连接建立了但消息发不通。这种时候升级一下conda activate ds conda update jupyter notebook ipykernel -y还有一个坑端口被占用导致内核无法绑定通信端口。Jupyter 和内核之间默认走本地随机端口如果系统里有奇怪的防火墙规则或者端口范围被限制也会连不上。临时关掉防火墙验证一下能连上就说明是防火墙规则问题。6.3 端口占用与连接被拒绝启动 Jupyter 报Address already in use说明 8888 端口被占了。先查是谁占的sudo ss -ltnp | grep :8888 sudo lsof -i :8888拿到 PID 之后要么 kill 掉要么换个端口启动。换端口是最省事的jupyter notebook --port8890改配置文件里的c.ServerApp.port一劳永逸。浏览器显示“连接被拒绝”或者“无法访问此网站”分几种情况。如果在服务器本机用 curl 测试能通但远程访问不通那是监听地址或者防火墙的问题curl -I http://127.0.0.1:8888本机能通检查防火墙规则和c.ServerApp.ip配置本机也不通说明服务没起来看日志。日志里的关键信息是启动时打印的地址行会明确写Serving notebooks from local directory和The Jupyter Notebook is running at。如果日志里显示的是http://localhost:8888而不是http://0.0.0.0:8888说明你的ip配置没生效大概率是配置项前缀写错了新版该用ServerApp你还在用NotebookApp。另外云服务器上还有一层安全组这个不在系统里要去服务商的控制台放行端口很多人卡在这里半天找不到原因。6.4 依赖类报错的处理思路有一类报错看着吓人其实处理思路很统一。典型的是ImportError: DLL load failed while importing xxx这在 Windows 上特别常见Linux 上偶尔也会遇到类似形态的动态库加载失败。Linux 环境下先用 ldd 看依赖链ldd $(python -c import numpy; print(numpy.__file__))输出里如果有not found的条目那就是缺系统库。根据缺失的库名去 apt 里找对应的包装上。比如libgomp.so.1缺失sudo apt install libgomp1就能解决。另一类是纯粹的 Python 层面的版本冲突典型报错是cannot import name xxx from partially initialized module或者module has no attribute。这种基本是包版本对不上。排查方法pip show 包名 conda list | grep 包名如果 pip 和 conda 各看到一份那就是混装导致的卸载其中一份统一用 conda 重装。还有一种情况是环境串了。明明激活的是 ds 环境import 的却是 base 里的包。用这个命令确认python -c import sys; print(sys.path)输出的路径里如果混进了其他环境的 site-packages那多半是 PYTHONPATH 环境变量被污染了。检查echo $PYTHONPATH有内容就清掉.bashrc里如果有export PYTHONPATH...的语句注释掉。6.5 常见问题速查表把上面这些整理成一张表出问题的时候直接对照着看现象最可能的原因快速验证命令处理方式conda: command not foundshell 未初始化或 PATH 被覆盖grep conda ~/.bashrc重新 conda init调整 PATH 顺序Jupyter 启动即退出配置项前缀错误或端口占用cat ~/jupyter.log改用 ServerApp 前缀换端口单元格一直转圈无结果内核未启动或内存不足ps aux | grep ipykernel重新注册内核加 swap内核被反复重启OOM Killer 杀进程dmesg | grep -i killed减小数据量或加内存远程访问连接被拒绝监听地址或防火墙curl -I http://127.0.0.1:8888检查 ip 配置与防火墙内核列表里没有新环境未注册 ipykerneljupyter kernelspec list执行 ipykernel install装包卡在 Solving environment源太多求解慢观察终端输出精简 .condarc 里的源import 报动态库缺失系统依赖包不全ldd 模块路径apt 装对应 lib 包环境文件换机后安装失败prefix 字段残留tail environment.yml删掉 prefix 行磁盘空间不足pkgs 缓存膨胀du -sh ~/anaconda3/pkgsconda clean -a清理conda clean -a这个命令值得单独说一句它会清掉下载缓存、索引缓存、未使用的包用久了能释放出好几个 GB。但注意它会删掉所有未使用环境的包缓存下次创建环境时又要重新下载所以别删得太频繁一个月一次差不多。提示排查问题的时候养成先看日志的习惯。Jupyter 的日志、systemd 的journalctl -u jupyter、dmesg 的内核日志这三个地方藏着百分之八十的答案。很多人的问题是遇到报错就瞎搜而不是先看手头这份日志到底说了什么。我个人在这些年反复配环境的过程中最大的体会是Anaconda 和 Jupyter 这套组合的坑百分之九十集中在“环境切换”和“配置项版本差异”这两个点上。前者靠which python和jupyter kernelspec list两个命令基本能定位后者靠确认自己装的是 Notebook 7 还是 6 以及对应的配置前缀。养成每次装完环境就顺手注册内核、每次改配置就重启一次的习惯能省掉大量“明明改了却不生效”的困惑。