内网机器上跑一段 Python 代码最烦的不是代码本身是conda create敲下去之后那一行Solving environment: failed。Conda 环境离线部署这件事听起来像是把文件拷过去那么简单真做过几轮就知道卡人的从来不是拷贝是依赖树、是平台 ABI、是那条被悄悄改写的 shebang。这篇东西写给谁手里有一台或者一批不联外网的机器、需要稳定可复现地把 Python 环境搬过去的人被包拷过去了却起不来折磨过几次、想搞清楚每种方案边界在哪的人。刚接手运维的同学和写代码顺带管环境的算法同学看完至少能判断自己手上那台机器该走哪条路以及走错了会在哪一步翻车。1. 先把问题拆开无网络环境到底缺什么1.1 离线部署的四个硬约束很多人把离线部署理解成把包文件复制过去这个理解只对了一半。一个 conda 环境的正常运行背后其实有四层东西在支撑缺任何一层都会出问题而每一层的解决难度完全不同。第一层是包文件本体。也就是.conda或.tar.bz2格式的压缩包里面是编译好的 Python 包、二进制扩展、头文件、元数据。这一层最容易搬rsync或者scp就完事。第二层是依赖解析所需的索引信息。conda 在安装时不是拿到一个包就装它要去频道的repodata.json里读每个包的依赖声明、版本约束、构建号build string然后解出一棵满足所有约束的依赖树。离线环境里如果没有这份索引或者索引是空的conda install第一步就崩报PackagesNotFoundError。第三层是平台与 ABI 的匹配。conda 频道是按子目录组织的linux-64、osx-arm64、win-64、noarch。你在一台linux-64上打的包拿到另一台linux-64上未必能跑——glibc 版本、libstdc 版本、CPU 指令集比如 AVX2 优化过的包在老的 CPU 上直接Illegal instruction都是隐藏的雷。noarch是纯 Python 包这一层最安全。第四层是环境前缀的硬编码路径。这是最容易被忽略、也最坑的一层。Python 环境里有一堆文件写死了绝对路径bin/pip这个脚本的第一行是#!/opt/conda/envs/ml/bin/pythonbin/jupyter同理conda-meta里的记录、.pth文件、脚本里的sys.prefix相关配置全都是绝对路径。你把环境从/opt/conda/envs/ml挪到/data/envs/ml这些路径就全错了表现是command not found或者 Python 找不到自己的库。搞清楚了这四层就能理解为什么市面上会有好几种方案——每种方案本质上是在用不同的方式处理这四层取舍点在于操作复杂度、能否保留 conda 的依赖解析能力、以及迁移后的可维护性。1.2 三种方案的定位与选型判据下面要展开的三种方案不是互斥的也不存在哪个最好。它们各自对应一类真实的落地场景我按从粗放到精细的顺序排。方案核心手法依赖解析适用场景主要代价conda-pack 整体打包把整个环境目录打成一个归档在联网机完成环境已定型、目标机只需运行无法再增减包跨平台窗口窄自建离线频道用conda index生成 repodata在离线机完成目标机需要灵活装包、多环境共用前期搭频道工作量大pkgs 缓存直搬 wheelhouse搬缓存目录和 pip 轮子离线机有限解析已有联网机做同构环境、以 pip 包为主依赖包元数据缺失时解析失败判断自己该走哪条问三个问题就够了。第一目标机上还需要再装新包吗如果需要方案一直接出局因为它打完包就冻结了你没法在里面conda install新东西甚至连路径上的硬编码都要靠conda-unpack修。第二目标机器是几台如果是一台方案一最省事如果是二十台方案二一次性搭好频道后面每台机器都能按需装长期成本反而低。第三你的依赖里 pip 包占比多少如果项目重度依赖内网 Git 仓库或者私有 PyPI 上的包那基本绕不开方案三里的 wheelhouse。有个反直觉的经验方案一conda-pack在生产环境里其实是三种方案中出问题最多的。原因不在工具本身而在于它把环境的运行时快照和可维护性一起冻住了一旦目标机环境和打包机有任何 glibc、驱动、CUDA 版本的细微差别报错信息还特别不直观——你看到的是ImportError: libcudart.so.11.0: cannot open shared object file但真实原因是驱动版本对不上。2. 方案一conda-pack 整体打包省事但边界很硬2.1 它到底做了什么从原理看坑在哪conda-pack的行为说起来简单递归收集指定环境目录下的所有文件排除pkgs缓存、__pycache__、*.pyc这类可再生内容打成一个 tar.gz另附一份conda-meta元数据清单。解压到目标机后你再运行一个叫conda-unpack的脚本完成收尾。关键在于conda-unpack这一步。它做的事是前缀重定位扫描环境内所有文本文件把打包时的前缀字符串比如/opt/conda/envs/ml替换成解压后的实际路径。同时它会顺手修掉那些以硬编码 shebang 开头的可执行脚本。所以不跑conda-unpack就直接用基本必然翻车。理解了这一点就能明白为什么它跨平台能力几乎为零。包里装的是已经编译好的二进制linux-64的.so文件拿到win-64上没有任何意义。noarch的纯 Python 包倒是可以跨但一个真实环境里不可能只有 noarch 包。所以下面这条规矩必须记住conda-pack 只能在相同操作系统、相同架构、且目标机 glibc 版本不低于打包机的前提下使用。glibc 这条尤其要注意它是单向兼容的。高版本 glibc 编译出来的二进制依赖GLIBC_2.28这类符号版本拿到 glibc 2.17 的机器上跑报错是version GLIBC_2.28 not found。反过来低版本打的包拿高版本跑一般没事。实操里的正确做法是永远在版本更老的那台机器上打包或者在一台刻意压低 glibc 的容器里打包。2.2 完整操作流程与参数详解联网机上的打包动作我一般这么写# 1. 建一个干净的打包专用环境不要让 conda-pack 去污染业务环境 conda create -n packer python3.10 -y conda activate packer conda install -c conda-forge conda-pack -y # 2. 打包目标环境注意不是当前激活的 packer 环境 conda pack -n ml-prod \ --ignore-editable-packages \ --exclude *.pyc \ --exclude tests \ --exclude */tests/* \ -o /data/artifacts/ml-prod-20240612.tar.gz \ --format tar.gz \ --compress-level 6 # 3. 生成校验和这一步别省 sha256sum /data/artifacts/ml-prod-20240612.tar.gz /data/artifacts/ml-prod-20240612.sha256几个参数值得单独说。--ignore-editable-packages处理的是pip install -e .装的可编辑包这种包的元数据指向源码目录如果源码不在目标机上打包时会直接报错退出加上这个参数就跳过它们——但你要自己保证目标机上有对应的源码。--exclude支持 glob 通配用来剔除测试数据、日志、__pycache__这类体积大又没用的东西我一个带 torch 的环境靠这个能把包从 4.2G 压到 2.6G。--compress-level取值范围 0-9默认 4设到 6 是一个体积和耗时的平衡点再往上收益递减得厉害。目标机上的解压和收尾# 1. 目标目录结构先建好 mkdir -p /data/envs/ml-prod # 2. 解压 tar -xzf ml-prod-20240612.tar.gz -C /data/envs/ml-prod # 3. 激活并修复前缀两步顺序不能反 source /data/envs/ml-prod/bin/activate conda-unpack # 4. 验证 python -c import sys; print(sys.prefix) which pipconda-unpack这一步有个细节它本身就在环境的bin/目录下所以你得先激活环境才能直接敲命令或者用绝对路径/data/envs/ml-prod/bin/conda-unpack也行。跑完之后它不会打印什么成功提示静默通过这时候你可以用grep -r /opt/conda/envs/ml-prod /data/envs/ml-prod/bin/ | head检查一下有没有残留的旧路径。2.3 平台一致性与文件占用这两类现场翻车Windows 上的情况和 Linux 差异不小值得单拎出来说。Windows 环境打包时绝对不要激活待打包的那个环境因为 Windows 有文件锁机制激活状态下python.exe、DLLs/*.pyd会被进程占用conda pack会报PermissionError: [WinError 32] 另一个程序正在使用此文件。正确做法是在 base 或者其他环境里执行conda pack -n target-env。解压后的收尾脚本也不一样是Scripts\conda-unpack.exe。还有一个 Windows 特有的坑路径长度限制。conda 环境的目录层级本来就深site-packages下面再套几层包名很容易超过 260 字符tar解压时直接报path too long。解决办法是把环境解压到盘符根目录下的短路径比如D:\e\ml或者提前在目标机打开长路径支持。这个坑我在两台机器上撞过第二次才开始习惯性地把环境放在短路径下。再补充一个容易被忽视的操作禁忌conda-unpack跑完之后如果你又在里面用 pip 装了新东西pip 会重新写入新的 shebang可能又变回错误的前缀。所以方案一的正确使用姿势是一次打包、一次收尾、之后只读不改。真要改就在联网机上改完重新打包别在离线机上手动打补丁——那会让可复现这三个字彻底失效。3. 方案二自建离线频道把 conda 的解析能力保住3.1 用 conda index 生成一份能被识别的 repodata方案二的核心思路是不去规避 conda 的依赖解析而是把解析所需的原料——也就是频道目录和repodata.json——一起搬过去让离线机上的 conda 像访问远程频道一样访问本地目录。这条路前期搭起来最费劲但一旦搭好长期收益最高。目录结构必须严格按 conda 的频道约定来子目录名就是平台标识一个字母都不能错mkdir -p /srv/offline-channel/{linux-64,noarch,win-64}把下载好的包文件按平台放进去。noarch的纯 Python 包装noarch/带二进制扩展的装对应平台目录。这一步最容易出错的是把 noarch 包装进了 linux-64表面上conda index也能跑通但客户端解析时可能因为找不到匹配的 subdir 而报PackagesNotFoundError排查起来相当费时间。生成本地频道索引# 新版推荐用独立的 conda-index 包功能更全也支持 .conda 格式 conda install -c conda-forge conda-index -y python -m conda_index /srv/offline-channel # 检查生成结果每个子目录下应该出现 repodata.json 及其压缩版本 ls -la /srv/offline-channel/linux-64/ | grep repodata正常情况下会生成repodata.json、repodata.json.bz2、repodata.json.zst三个文件。conda 客户端会优先拉.zst其次.bz2最后才是明文 JSON。所以压缩文件损坏或者没同步客户端也会解析失败这个细节很多教程没写但你一旦遇到本地目录明明有包却装不上先看这三个文件是不是齐全。3.2 离线机上的 .condarc 与安装命令客户端侧需要一份明确的频道配置。写进~/.condarc或者项目目录下的.condarcchannels: - file:///srv/offline-channel - defaults channel_priority: strict offline: true show_channel_urls: truechannel_priority: strict这个配置要理解清楚它保证同名包只从优先级最高的频道里取不会出现这个包装了 A 频道的 numpy那个包拉了 B 频道的 numpy这种混装。离线场景下我强烈建议开 strict因为你的本地频道里包的版本是人为挑选的混装很容易出现二进制不兼容。offline: true则让 conda 彻底不发起任何网络请求把所有连接错误扼杀在源头而不是等超时报错。安装命令conda create -n py310 --offline \ -c file:///srv/offline-channel \ python3.10 numpy1.24 pandas2.0 \ -y如果报PackagesNotFoundError用这条命令定位缺什么conda search --offline -c file:///srv/offline-channel numpy --info还有一种简化的写法前提是包都放在 conda 的conda-bld目录下这个目录被隐式当作一个叫local的频道conda install --use-local numpy。--use-local本质上就是把conda-bld当作频道使用适合快速验证单个包不适合长期维护。3.3 依赖白名单怎么生成用 explicit 清单反推包列表这是方案二里最容易做错、也最有技巧的一步。你不能靠我要 numpy 和 pandas那就下这两个这种思路因为 numpy 自己要依赖blas、libgfortran、python_abipandas 又依赖pytz、dateutil、numpy链式展开下来可能几十个包。手工找齐几乎不可能。正确做法是在一台联网机上用最小化的方式做一次预演安装把最终解析出来的完整包列表导出来# 联网机只下载不安装把包落到 pkgs 缓存 conda create -p /tmp/stage --download-only \ -c conda-forge \ python3.10 numpy pandas scikit-learn -y # 导出精确清单这个文件里是带完整 URL 的包列表 conda list --explicit -p /tmp/stage /tmp/stage-explicit.txt # 文件长这样 # EXPLICIT # https://conda.anaconda.org/conda-forge/linux-64/numpy-1.24.3-py310h...conda # https://conda.anaconda.org/conda-forge/noarch/pytz-2023.3-pyhd8ed1ab_0.conda有了这份清单把 URL 里的 subdir 段linux-64或noarch抽出来就能把对应的包文件自动归类到频道目录里。我一般用一小段 shell 做这件事grep -v ^ /tmp/stage-explicit.txt | while read -r url; do fname$(basename $url) subdir$(echo $url | awk -F/ {print $(NF-1)}) cp $HOME/miniconda3/pkgs/$fname /srv/offline-channel/$subdir/ 2/dev/null \ || echo MISSING: $fname done # 重新生成索引 python -m conda_index /srv/offline-channel那段MISSING打印很关键它告诉你哪个包没从缓存里找到需要单独补下载。3.4 频道优先级与包版本漂移的两处隐雷第一处雷是默认频道的服务条款确认问题。较新版本的 conda 在使用默认频道时会要求确认服务条款离线机上这个确认动作如果没提前做过conda create会卡在一个交互提示或者直接失败。稳妥的做法是离线机的.condarc里只保留file://本地频道根本不去碰默认频道或者提前在联网机上完成确认把.condarc连同相关配置一起同步过去。如果你的依赖全部来自社区频道那把默认频道整个删掉是最省心的。第二处雷是版本漂移。离线频道里的包版本是静态的但你的environment.yml里如果写的是numpy1.20这种宽约束今天解析出来的和三个月后新同事照文档操作解析出来的结果可能不一样——因为中间你往频道里补过新版本的包。企业级做法是用conda-lock把解析结果锁死生成一份带完整 URL 和 sha256 的锁文件离线机上照着锁文件装保证每个人拿到的字节完全一致。# 联网机 conda install -c conda-forge conda-lock -y conda-lock lock -f environment.yml -p linux-64 # 会生成 conda-lock.yml内含每个包的精确 URL 与 hash # 离线机装的时候 conda-lock install --offline --prefix /data/envs/app conda-lock.yml4. 方案三pkgs 缓存直搬加上 pip wheelhouse 混合打法4.1 搬 pkgs 缓存前必须搞清楚的事conda 的pkgs_dirs是一个很有意思的目录。它既是下载缓存又是环境构建时的源——conda 创建环境时不是重新解压包而是用硬链接把 pkgs 缓存里的文件链接到环境目录。理解这一点非常关键因为它直接决定了你搬缓存的方式。先看当前配置conda config --show pkgs_dirs # 典型输出 # pkgs_dirs: # - /home/user/miniconda3/pkgs # - /home/user/.conda/pkgsconda 会按顺序在这几个目录里找包找到就用。所以离线机上的策略很简单把联网机上完整的pkgs目录原样搬过去然后让 pkgs_dirs 指过去。但原样这两个字有讲究。因为 pkgs 目录里的解压文件夹和压缩包之间是硬链接关系如果你用cp -r复制硬链接关系会被打断变成两份真实数据体积翻倍不说后续conda clean的行为也会异常。正确做法是保持硬链接地传输# 推荐tar 管道保留硬链接 tar -C /home/user/miniconda3 -cf - pkgs | \ ssh target-host tar -C /home/user/miniconda3 -xf - # 同机内移动用 cp -a cp -a /home/user/miniconda3/pkgs /mnt/usb/pkgs传完之后离线机上确认 pkgs_dirs 指向正确然后直接按 explicit 清单建环境# 先确认 pkgs_dirs 配置生效 conda config --set pkgs_dirs /home/user/miniconda3/pkgs conda config --show pkgs_dirs # 用 explicit 清单离线建环境 conda create -n app --offline --file /path/to/explicit.txt -y # 验证所有包都应该有来源不应该出现 pip 标记 conda list -n app | head -30这里有个必须反复提醒的禁忌离线机上的conda clean一个选项都不要碰。conda clean --packages会清掉 pkgs 缓存里没有被任何环境引用的包conda clean --all更狠连索引缓存一起删。对离线机器来说pkgs 缓存就是你的安装源删掉之后想再装任何东西都没戏了只能重新从外网搬一次。我刚接手的时候不知道这条一次conda clean -a把一台机器的缓存清干净了后面补了半天。4.2 pip wheelhouse把轮子按目标平台下全conda 解决不了一切生物信息、深度学习这些领域的包很多只在 PyPI 上有。这部分就得靠pip download交叉下载。核心命令mkdir -p /data/wheelhouse pip download -r requirements.txt \ -d /data/wheelhouse \ --platform manylinux2014_x86_64 \ --python-version 310 \ --implementation cp \ --abi cp310 \ --only-binary:all:这几个参数一个都不能少而且它们之间有强依赖关系--platform必须和--only-binary:all:一起用否则 pip 会直接报错When restricting platform and interpreter constraints, either --no-deps must be set, or --only-binary:all: must be set。这条报错信息写得挺清楚但第一次见的人多半会懵。manylinux2014_x86_64对应 glibc 2.17 及以上兼容性最广。如果你确定目标机很新用manylinux_2_28_x86_64能拿到更新的轮子目标机是老古董就得往下找manylinux1_x86_64glibc 2.5。这个标签选错装上去运行时报GLIBC_2.28 not found和前面 conda-pack 那个坑是同一个根因。--python-version 310和--abi cp310是配套的前者是版本号注意不带点后者是 ABI 标签。cp310 表示 CPython 3.10如果你的环境是 3.9 就改成39和cp39。有些包没有提供 wheel只有 sdist源码包。--only-binary:all:会导致它们在下载阶段直接失败。处理方式是单独跑一遍不带--only-binary的下载但要注意sdist 在离线机安装时需要编译意味着目标机上要有 gcc、g、Python 头文件还要有包依赖的系统库。如果目标机是纯净的最小化安装这条路基本走不通得提前在联网机上用pip wheel把源码包编译成 wheel 带过去# 在联网机上把 sdist 编译成 wheel pip wheel -r requirements.txt -w /data/wheelhouse \ --no-deps # 依赖已经单独下过了这里只处理编译离线机上的安装pip install \ --no-index \ --find-links/data/wheelhouse \ -r requirements.txt--no-index是必须的它告诉 pip 完全不要尝试连 PyPI--find-links指向本地目录。这两条一起用才是真正的离线安装只写--find-links不写--no-indexpip 在本地找不到时会去网上找然后卡在一个超时上表现出来的现象是装了半天没动静。4.3 conda 与 pip 混装时的冲突处理混合方案的现场事故八成出在 conda 和 pip 互相覆盖上。典型场景conda 装了numpy 1.24之后pip install某个包时顺手把numpy升级到了1.26结果 conda 的conda-meta里仍记着 1.24conda list显示 1.26 旁边挂了个pip标记环境进入一种两个包管理器都认为自己说了算的薛定谔状态。处理原则我总结成三条。第一顺序固定先 conda 后 pip把能用 conda 解决的依赖尽量在 conda 层装完。第二pip 安装时加--no-deps逐个装尤其是那些依赖 numpy/scipy 的包避免 pip 自作主张重装科学栈。第三装完立刻验证# 检查有没有 pip 覆盖 conda 包的痕迹 conda list -n app | grep pip # 检查依赖树是否一致 pip checkpip check会输出所有版本冲突conda list里的pip标记则告诉你哪些包的管理权已经跑到 pip 那边了。这两个信号一旦出现我的做法不是修补是回滚重建——离线环境里的依赖树一旦被搞乱靠手工修回来的成本远高于照 explicit 清单重建一次而且重建出来的结果是可复现的修出来的不是。5. 三种方案横向对比与企业级配套措施5.1 一张表看清取舍评估维度conda-pack离线频道缓存直搬 wheelhouse首次搭建耗时20 分钟2-4 小时含包收集1-2 小时目标机能否新增包否只读快照能受频道内容限制能受缓存内容限制依赖解析在哪完成联网机离线机联网机为主跨平台能力仅同平台频道可含多平台仅同平台多机分发成本高每台都要传整包低共享频道中体积中等压缩后大含全平台包最大缓存轮子出问题后的可诊断性差二进制黑盒好日志清晰中适合的团队规模1-3 人5 人以上2-10 人表格里的可诊断性这一项是我自己踩坑之后加进去的维度。conda-pack 出问题时你面对的是一个几百兆的二进制包报错信息只有一个ImportError得靠ldd、readelf一点点倒推而离线频道方案里conda 会明确告诉你哪个包的哪个依赖版本约束不满足排查路径短得多。所以在多人协作的团队里我更倾向推方案二。5.2 归档规范、校验与回滚这三件事前面讲的都是怎么让环境跑起来企业级落地还要多问一句三个月后新同事还能 Reproduction 吗这就需要三样东西。归档目录规范。我习惯按日期-环境名-平台-哈希前八位命名一个环境的所有产物放在同一个目录下包括包文件、explicit 清单、.condarc副本、构建脚本、校验和文件。目录一旦定下来就不要改结构因为半年后你会写自动化脚本去扫这些目录。/data/artifacts/20240612-ml-prod-linux64-a1b2c3d4/ ├── ml-prod-20240612.tar.gz # conda-pack 产物 ├── ml-prod-20240612.sha256 ├── explicit-linux64.txt # 精确包清单 ├── wheelhouse/ # pip 轮子 ├── condarc.backup # 客户端配置 └── BUILD.md # 构建说明与已知问题校验和。传输环节的静默损坏比想象中常见尤其是通过 U 盘、内网文件共享这类介质。sha256 校验必须做而且要在解压之前做。校验失败就直接重传不要抱侥幸心理去解压——我见过一次 tar 包尾部损坏导致解压出来的环境缺了几个.so排查了两小时才发现是传输问题。回滚。离线机上新环境上线前先mv老环境到envs/.backup/再部署新的出问题一条mv就回去了。相比就地升级这个习惯救过我至少三次。配合conda env list手动指定envs_dirs也能让 conda 认出这些非标准路径下的环境。6. 现场排查那些报错背后真正的意思6.1 高频故障的定位思路CondaHTTPError: Connection refused或长时间卡在Solving environment。离线机上出现连接类错误八成是没加--offline或者.condarc里还留着远程频道。用conda config --show channels确认一下把所有https://开头的频道删掉再加--offline重试。PackagesNotFoundError: The following packages are not available from current channels。先别怀疑包没下全用conda search --offline -c file:///your-channel pkg直接查。如果搜得到但装不上问题多半在依赖约束上——某个间接依赖的版本区间在频道里找不到匹配。用--info参数看包的所有 build 和依赖声明往往能发现是个python_abi或libgcc-ng的版本卡住了。conda-unpack: command not found。两种情况一是环境没激活二是conda-unpack没被正确打包进bin/。先检查ls /data/envs/xxx/bin/ | grep conda-unpack。如果文件在但还是找不到说明 PATH 没生效用绝对路径执行。ImportError: libxxx.so: cannot open shared object file。这不是 Python 层的问题是动态链接器找不到共享库。用ldd /path/to/xxx.so | grep not found定位缺哪个然后判断是LD_LIBRARY_PATH没设还是包里根本没有这个.so后者常见于 conda-pack 跨机器迁移时某些系统的库被假定存在。ERROR: Could not find a version that satisfies the requirement xxxpip 阶段。离线安装时报这个通常不是 wheelhouse 里没有而是目标 Python 版本和轮子的 ABI 标签对不上。检查pip --version显示的 Python 版本再看 wheelhouse 里文件的命名后缀是不是cp310而目标机是cp39。CondaVerificationError: The package for xxx located at ... appears to be corrupted。sha256 不匹配或者包文件被截断。先conda clean --tarballs清掉这个包再重新从归档里拷一份过来。注意这里的conda clean --tarballs只清压缩包不清解压目录相对安全但离线环境里我仍然建议手工rm指定文件而不是跑 clean。6.2 速查表现象最可能原因快速验证处理装包时卡住不动未启用离线模式conda config --show offline加--offline或设offline: true包搜不到频道里没有该 subdirls /srv/offline-channel/linux-64 | grep 包名补包到正确子目录后重新conda_index环境能激活但命令找不到shebang 路径未修复head -1 envs/x/bin/pip执行conda-unpack二进制导入报 GLIBC 错误打包机 glibc 高于目标机ldd --version对比两端在低版本机重新打包pip 离线装不上ABI 标签不匹配ls wheelhouse | grep cp3用目标机版本重新下载环境体积异常大硬链接被打断du -sh与源端对比用 tar 或cp -a重新传输Windows 打包报文件占用环境处于激活状态看激活项换环境执行conda pack多环境同名包冲突频道优先级非 strictconda config --show channel_priority设为strict这张表我打印贴在机房过后来发现真正用得上的只有前三行但后五行属于遇见一次记一辈子的类型。最后分享一个实际用的技巧在离线机上建一个体检脚本把conda --version、conda config --show channels、conda config --show offline、conda env list、pip --version、pip check这几条的输出全部落到一个日志文件里每部署一台机器跑一次。排查问题的时候先看这份日志能快速排除掉配置没生效这类低级但高发的故障——我遇到过三次明明改了.condarc但没生效原因是同一个用户目录下还有一份优先级更高的配置文件在起作用。
内网机器上跑一段 Python 代码最烦的不是代码本身是conda create敲下去之后那一行Solving environment: failed。Conda 环境离线部署这件事听起来像是把文件拷过去那么简单真做过几轮就知道卡人的从来不是拷贝是依赖树、是平台 ABI、是那条被悄悄改写的 shebang。这篇东西写给谁手里有一台或者一批不联外网的机器、需要稳定可复现地把 Python 环境搬过去的人被包拷过去了却起不来折磨过几次、想搞清楚每种方案边界在哪的人。刚接手运维的同学和写代码顺带管环境的算法同学看完至少能判断自己手上那台机器该走哪条路以及走错了会在哪一步翻车。1. 先把问题拆开无网络环境到底缺什么1.1 离线部署的四个硬约束很多人把离线部署理解成把包文件复制过去这个理解只对了一半。一个 conda 环境的正常运行背后其实有四层东西在支撑缺任何一层都会出问题而每一层的解决难度完全不同。第一层是包文件本体。也就是.conda或.tar.bz2格式的压缩包里面是编译好的 Python 包、二进制扩展、头文件、元数据。这一层最容易搬rsync或者scp就完事。第二层是依赖解析所需的索引信息。conda 在安装时不是拿到一个包就装它要去频道的repodata.json里读每个包的依赖声明、版本约束、构建号build string然后解出一棵满足所有约束的依赖树。离线环境里如果没有这份索引或者索引是空的conda install第一步就崩报PackagesNotFoundError。第三层是平台与 ABI 的匹配。conda 频道是按子目录组织的linux-64、osx-arm64、win-64、noarch。你在一台linux-64上打的包拿到另一台linux-64上未必能跑——glibc 版本、libstdc 版本、CPU 指令集比如 AVX2 优化过的包在老的 CPU 上直接Illegal instruction都是隐藏的雷。noarch是纯 Python 包这一层最安全。第四层是环境前缀的硬编码路径。这是最容易被忽略、也最坑的一层。Python 环境里有一堆文件写死了绝对路径bin/pip这个脚本的第一行是#!/opt/conda/envs/ml/bin/pythonbin/jupyter同理conda-meta里的记录、.pth文件、脚本里的sys.prefix相关配置全都是绝对路径。你把环境从/opt/conda/envs/ml挪到/data/envs/ml这些路径就全错了表现是command not found或者 Python 找不到自己的库。搞清楚了这四层就能理解为什么市面上会有好几种方案——每种方案本质上是在用不同的方式处理这四层取舍点在于操作复杂度、能否保留 conda 的依赖解析能力、以及迁移后的可维护性。1.2 三种方案的定位与选型判据下面要展开的三种方案不是互斥的也不存在哪个最好。它们各自对应一类真实的落地场景我按从粗放到精细的顺序排。方案核心手法依赖解析适用场景主要代价conda-pack 整体打包把整个环境目录打成一个归档在联网机完成环境已定型、目标机只需运行无法再增减包跨平台窗口窄自建离线频道用conda index生成 repodata在离线机完成目标机需要灵活装包、多环境共用前期搭频道工作量大pkgs 缓存直搬 wheelhouse搬缓存目录和 pip 轮子离线机有限解析已有联网机做同构环境、以 pip 包为主依赖包元数据缺失时解析失败判断自己该走哪条问三个问题就够了。第一目标机上还需要再装新包吗如果需要方案一直接出局因为它打完包就冻结了你没法在里面conda install新东西甚至连路径上的硬编码都要靠conda-unpack修。第二目标机器是几台如果是一台方案一最省事如果是二十台方案二一次性搭好频道后面每台机器都能按需装长期成本反而低。第三你的依赖里 pip 包占比多少如果项目重度依赖内网 Git 仓库或者私有 PyPI 上的包那基本绕不开方案三里的 wheelhouse。有个反直觉的经验方案一conda-pack在生产环境里其实是三种方案中出问题最多的。原因不在工具本身而在于它把环境的运行时快照和可维护性一起冻住了一旦目标机环境和打包机有任何 glibc、驱动、CUDA 版本的细微差别报错信息还特别不直观——你看到的是ImportError: libcudart.so.11.0: cannot open shared object file但真实原因是驱动版本对不上。2. 方案一conda-pack 整体打包省事但边界很硬2.1 它到底做了什么从原理看坑在哪conda-pack的行为说起来简单递归收集指定环境目录下的所有文件排除pkgs缓存、__pycache__、*.pyc这类可再生内容打成一个 tar.gz另附一份conda-meta元数据清单。解压到目标机后你再运行一个叫conda-unpack的脚本完成收尾。关键在于conda-unpack这一步。它做的事是前缀重定位扫描环境内所有文本文件把打包时的前缀字符串比如/opt/conda/envs/ml替换成解压后的实际路径。同时它会顺手修掉那些以硬编码 shebang 开头的可执行脚本。所以不跑conda-unpack就直接用基本必然翻车。理解了这一点就能明白为什么它跨平台能力几乎为零。包里装的是已经编译好的二进制linux-64的.so文件拿到win-64上没有任何意义。noarch的纯 Python 包倒是可以跨但一个真实环境里不可能只有 noarch 包。所以下面这条规矩必须记住conda-pack 只能在相同操作系统、相同架构、且目标机 glibc 版本不低于打包机的前提下使用。glibc 这条尤其要注意它是单向兼容的。高版本 glibc 编译出来的二进制依赖GLIBC_2.28这类符号版本拿到 glibc 2.17 的机器上跑报错是version GLIBC_2.28 not found。反过来低版本打的包拿高版本跑一般没事。实操里的正确做法是永远在版本更老的那台机器上打包或者在一台刻意压低 glibc 的容器里打包。2.2 完整操作流程与参数详解联网机上的打包动作我一般这么写# 1. 建一个干净的打包专用环境不要让 conda-pack 去污染业务环境 conda create -n packer python3.10 -y conda activate packer conda install -c conda-forge conda-pack -y # 2. 打包目标环境注意不是当前激活的 packer 环境 conda pack -n ml-prod \ --ignore-editable-packages \ --exclude *.pyc \ --exclude tests \ --exclude */tests/* \ -o /data/artifacts/ml-prod-20240612.tar.gz \ --format tar.gz \ --compress-level 6 # 3. 生成校验和这一步别省 sha256sum /data/artifacts/ml-prod-20240612.tar.gz /data/artifacts/ml-prod-20240612.sha256几个参数值得单独说。--ignore-editable-packages处理的是pip install -e .装的可编辑包这种包的元数据指向源码目录如果源码不在目标机上打包时会直接报错退出加上这个参数就跳过它们——但你要自己保证目标机上有对应的源码。--exclude支持 glob 通配用来剔除测试数据、日志、__pycache__这类体积大又没用的东西我一个带 torch 的环境靠这个能把包从 4.2G 压到 2.6G。--compress-level取值范围 0-9默认 4设到 6 是一个体积和耗时的平衡点再往上收益递减得厉害。目标机上的解压和收尾# 1. 目标目录结构先建好 mkdir -p /data/envs/ml-prod # 2. 解压 tar -xzf ml-prod-20240612.tar.gz -C /data/envs/ml-prod # 3. 激活并修复前缀两步顺序不能反 source /data/envs/ml-prod/bin/activate conda-unpack # 4. 验证 python -c import sys; print(sys.prefix) which pipconda-unpack这一步有个细节它本身就在环境的bin/目录下所以你得先激活环境才能直接敲命令或者用绝对路径/data/envs/ml-prod/bin/conda-unpack也行。跑完之后它不会打印什么成功提示静默通过这时候你可以用grep -r /opt/conda/envs/ml-prod /data/envs/ml-prod/bin/ | head检查一下有没有残留的旧路径。2.3 平台一致性与文件占用这两类现场翻车Windows 上的情况和 Linux 差异不小值得单拎出来说。Windows 环境打包时绝对不要激活待打包的那个环境因为 Windows 有文件锁机制激活状态下python.exe、DLLs/*.pyd会被进程占用conda pack会报PermissionError: [WinError 32] 另一个程序正在使用此文件。正确做法是在 base 或者其他环境里执行conda pack -n target-env。解压后的收尾脚本也不一样是Scripts\conda-unpack.exe。还有一个 Windows 特有的坑路径长度限制。conda 环境的目录层级本来就深site-packages下面再套几层包名很容易超过 260 字符tar解压时直接报path too long。解决办法是把环境解压到盘符根目录下的短路径比如D:\e\ml或者提前在目标机打开长路径支持。这个坑我在两台机器上撞过第二次才开始习惯性地把环境放在短路径下。再补充一个容易被忽视的操作禁忌conda-unpack跑完之后如果你又在里面用 pip 装了新东西pip 会重新写入新的 shebang可能又变回错误的前缀。所以方案一的正确使用姿势是一次打包、一次收尾、之后只读不改。真要改就在联网机上改完重新打包别在离线机上手动打补丁——那会让可复现这三个字彻底失效。3. 方案二自建离线频道把 conda 的解析能力保住3.1 用 conda index 生成一份能被识别的 repodata方案二的核心思路是不去规避 conda 的依赖解析而是把解析所需的原料——也就是频道目录和repodata.json——一起搬过去让离线机上的 conda 像访问远程频道一样访问本地目录。这条路前期搭起来最费劲但一旦搭好长期收益最高。目录结构必须严格按 conda 的频道约定来子目录名就是平台标识一个字母都不能错mkdir -p /srv/offline-channel/{linux-64,noarch,win-64}把下载好的包文件按平台放进去。noarch的纯 Python 包装noarch/带二进制扩展的装对应平台目录。这一步最容易出错的是把 noarch 包装进了 linux-64表面上conda index也能跑通但客户端解析时可能因为找不到匹配的 subdir 而报PackagesNotFoundError排查起来相当费时间。生成本地频道索引# 新版推荐用独立的 conda-index 包功能更全也支持 .conda 格式 conda install -c conda-forge conda-index -y python -m conda_index /srv/offline-channel # 检查生成结果每个子目录下应该出现 repodata.json 及其压缩版本 ls -la /srv/offline-channel/linux-64/ | grep repodata正常情况下会生成repodata.json、repodata.json.bz2、repodata.json.zst三个文件。conda 客户端会优先拉.zst其次.bz2最后才是明文 JSON。所以压缩文件损坏或者没同步客户端也会解析失败这个细节很多教程没写但你一旦遇到本地目录明明有包却装不上先看这三个文件是不是齐全。3.2 离线机上的 .condarc 与安装命令客户端侧需要一份明确的频道配置。写进~/.condarc或者项目目录下的.condarcchannels: - file:///srv/offline-channel - defaults channel_priority: strict offline: true show_channel_urls: truechannel_priority: strict这个配置要理解清楚它保证同名包只从优先级最高的频道里取不会出现这个包装了 A 频道的 numpy那个包拉了 B 频道的 numpy这种混装。离线场景下我强烈建议开 strict因为你的本地频道里包的版本是人为挑选的混装很容易出现二进制不兼容。offline: true则让 conda 彻底不发起任何网络请求把所有连接错误扼杀在源头而不是等超时报错。安装命令conda create -n py310 --offline \ -c file:///srv/offline-channel \ python3.10 numpy1.24 pandas2.0 \ -y如果报PackagesNotFoundError用这条命令定位缺什么conda search --offline -c file:///srv/offline-channel numpy --info还有一种简化的写法前提是包都放在 conda 的conda-bld目录下这个目录被隐式当作一个叫local的频道conda install --use-local numpy。--use-local本质上就是把conda-bld当作频道使用适合快速验证单个包不适合长期维护。3.3 依赖白名单怎么生成用 explicit 清单反推包列表这是方案二里最容易做错、也最有技巧的一步。你不能靠我要 numpy 和 pandas那就下这两个这种思路因为 numpy 自己要依赖blas、libgfortran、python_abipandas 又依赖pytz、dateutil、numpy链式展开下来可能几十个包。手工找齐几乎不可能。正确做法是在一台联网机上用最小化的方式做一次预演安装把最终解析出来的完整包列表导出来# 联网机只下载不安装把包落到 pkgs 缓存 conda create -p /tmp/stage --download-only \ -c conda-forge \ python3.10 numpy pandas scikit-learn -y # 导出精确清单这个文件里是带完整 URL 的包列表 conda list --explicit -p /tmp/stage /tmp/stage-explicit.txt # 文件长这样 # EXPLICIT # https://conda.anaconda.org/conda-forge/linux-64/numpy-1.24.3-py310h...conda # https://conda.anaconda.org/conda-forge/noarch/pytz-2023.3-pyhd8ed1ab_0.conda有了这份清单把 URL 里的 subdir 段linux-64或noarch抽出来就能把对应的包文件自动归类到频道目录里。我一般用一小段 shell 做这件事grep -v ^ /tmp/stage-explicit.txt | while read -r url; do fname$(basename $url) subdir$(echo $url | awk -F/ {print $(NF-1)}) cp $HOME/miniconda3/pkgs/$fname /srv/offline-channel/$subdir/ 2/dev/null \ || echo MISSING: $fname done # 重新生成索引 python -m conda_index /srv/offline-channel那段MISSING打印很关键它告诉你哪个包没从缓存里找到需要单独补下载。3.4 频道优先级与包版本漂移的两处隐雷第一处雷是默认频道的服务条款确认问题。较新版本的 conda 在使用默认频道时会要求确认服务条款离线机上这个确认动作如果没提前做过conda create会卡在一个交互提示或者直接失败。稳妥的做法是离线机的.condarc里只保留file://本地频道根本不去碰默认频道或者提前在联网机上完成确认把.condarc连同相关配置一起同步过去。如果你的依赖全部来自社区频道那把默认频道整个删掉是最省心的。第二处雷是版本漂移。离线频道里的包版本是静态的但你的environment.yml里如果写的是numpy1.20这种宽约束今天解析出来的和三个月后新同事照文档操作解析出来的结果可能不一样——因为中间你往频道里补过新版本的包。企业级做法是用conda-lock把解析结果锁死生成一份带完整 URL 和 sha256 的锁文件离线机上照着锁文件装保证每个人拿到的字节完全一致。# 联网机 conda install -c conda-forge conda-lock -y conda-lock lock -f environment.yml -p linux-64 # 会生成 conda-lock.yml内含每个包的精确 URL 与 hash # 离线机装的时候 conda-lock install --offline --prefix /data/envs/app conda-lock.yml4. 方案三pkgs 缓存直搬加上 pip wheelhouse 混合打法4.1 搬 pkgs 缓存前必须搞清楚的事conda 的pkgs_dirs是一个很有意思的目录。它既是下载缓存又是环境构建时的源——conda 创建环境时不是重新解压包而是用硬链接把 pkgs 缓存里的文件链接到环境目录。理解这一点非常关键因为它直接决定了你搬缓存的方式。先看当前配置conda config --show pkgs_dirs # 典型输出 # pkgs_dirs: # - /home/user/miniconda3/pkgs # - /home/user/.conda/pkgsconda 会按顺序在这几个目录里找包找到就用。所以离线机上的策略很简单把联网机上完整的pkgs目录原样搬过去然后让 pkgs_dirs 指过去。但原样这两个字有讲究。因为 pkgs 目录里的解压文件夹和压缩包之间是硬链接关系如果你用cp -r复制硬链接关系会被打断变成两份真实数据体积翻倍不说后续conda clean的行为也会异常。正确做法是保持硬链接地传输# 推荐tar 管道保留硬链接 tar -C /home/user/miniconda3 -cf - pkgs | \ ssh target-host tar -C /home/user/miniconda3 -xf - # 同机内移动用 cp -a cp -a /home/user/miniconda3/pkgs /mnt/usb/pkgs传完之后离线机上确认 pkgs_dirs 指向正确然后直接按 explicit 清单建环境# 先确认 pkgs_dirs 配置生效 conda config --set pkgs_dirs /home/user/miniconda3/pkgs conda config --show pkgs_dirs # 用 explicit 清单离线建环境 conda create -n app --offline --file /path/to/explicit.txt -y # 验证所有包都应该有来源不应该出现 pip 标记 conda list -n app | head -30这里有个必须反复提醒的禁忌离线机上的conda clean一个选项都不要碰。conda clean --packages会清掉 pkgs 缓存里没有被任何环境引用的包conda clean --all更狠连索引缓存一起删。对离线机器来说pkgs 缓存就是你的安装源删掉之后想再装任何东西都没戏了只能重新从外网搬一次。我刚接手的时候不知道这条一次conda clean -a把一台机器的缓存清干净了后面补了半天。4.2 pip wheelhouse把轮子按目标平台下全conda 解决不了一切生物信息、深度学习这些领域的包很多只在 PyPI 上有。这部分就得靠pip download交叉下载。核心命令mkdir -p /data/wheelhouse pip download -r requirements.txt \ -d /data/wheelhouse \ --platform manylinux2014_x86_64 \ --python-version 310 \ --implementation cp \ --abi cp310 \ --only-binary:all:这几个参数一个都不能少而且它们之间有强依赖关系--platform必须和--only-binary:all:一起用否则 pip 会直接报错When restricting platform and interpreter constraints, either --no-deps must be set, or --only-binary:all: must be set。这条报错信息写得挺清楚但第一次见的人多半会懵。manylinux2014_x86_64对应 glibc 2.17 及以上兼容性最广。如果你确定目标机很新用manylinux_2_28_x86_64能拿到更新的轮子目标机是老古董就得往下找manylinux1_x86_64glibc 2.5。这个标签选错装上去运行时报GLIBC_2.28 not found和前面 conda-pack 那个坑是同一个根因。--python-version 310和--abi cp310是配套的前者是版本号注意不带点后者是 ABI 标签。cp310 表示 CPython 3.10如果你的环境是 3.9 就改成39和cp39。有些包没有提供 wheel只有 sdist源码包。--only-binary:all:会导致它们在下载阶段直接失败。处理方式是单独跑一遍不带--only-binary的下载但要注意sdist 在离线机安装时需要编译意味着目标机上要有 gcc、g、Python 头文件还要有包依赖的系统库。如果目标机是纯净的最小化安装这条路基本走不通得提前在联网机上用pip wheel把源码包编译成 wheel 带过去# 在联网机上把 sdist 编译成 wheel pip wheel -r requirements.txt -w /data/wheelhouse \ --no-deps # 依赖已经单独下过了这里只处理编译离线机上的安装pip install \ --no-index \ --find-links/data/wheelhouse \ -r requirements.txt--no-index是必须的它告诉 pip 完全不要尝试连 PyPI--find-links指向本地目录。这两条一起用才是真正的离线安装只写--find-links不写--no-indexpip 在本地找不到时会去网上找然后卡在一个超时上表现出来的现象是装了半天没动静。4.3 conda 与 pip 混装时的冲突处理混合方案的现场事故八成出在 conda 和 pip 互相覆盖上。典型场景conda 装了numpy 1.24之后pip install某个包时顺手把numpy升级到了1.26结果 conda 的conda-meta里仍记着 1.24conda list显示 1.26 旁边挂了个pip标记环境进入一种两个包管理器都认为自己说了算的薛定谔状态。处理原则我总结成三条。第一顺序固定先 conda 后 pip把能用 conda 解决的依赖尽量在 conda 层装完。第二pip 安装时加--no-deps逐个装尤其是那些依赖 numpy/scipy 的包避免 pip 自作主张重装科学栈。第三装完立刻验证# 检查有没有 pip 覆盖 conda 包的痕迹 conda list -n app | grep pip # 检查依赖树是否一致 pip checkpip check会输出所有版本冲突conda list里的pip标记则告诉你哪些包的管理权已经跑到 pip 那边了。这两个信号一旦出现我的做法不是修补是回滚重建——离线环境里的依赖树一旦被搞乱靠手工修回来的成本远高于照 explicit 清单重建一次而且重建出来的结果是可复现的修出来的不是。5. 三种方案横向对比与企业级配套措施5.1 一张表看清取舍评估维度conda-pack离线频道缓存直搬 wheelhouse首次搭建耗时20 分钟2-4 小时含包收集1-2 小时目标机能否新增包否只读快照能受频道内容限制能受缓存内容限制依赖解析在哪完成联网机离线机联网机为主跨平台能力仅同平台频道可含多平台仅同平台多机分发成本高每台都要传整包低共享频道中体积中等压缩后大含全平台包最大缓存轮子出问题后的可诊断性差二进制黑盒好日志清晰中适合的团队规模1-3 人5 人以上2-10 人表格里的可诊断性这一项是我自己踩坑之后加进去的维度。conda-pack 出问题时你面对的是一个几百兆的二进制包报错信息只有一个ImportError得靠ldd、readelf一点点倒推而离线频道方案里conda 会明确告诉你哪个包的哪个依赖版本约束不满足排查路径短得多。所以在多人协作的团队里我更倾向推方案二。5.2 归档规范、校验与回滚这三件事前面讲的都是怎么让环境跑起来企业级落地还要多问一句三个月后新同事还能 Reproduction 吗这就需要三样东西。归档目录规范。我习惯按日期-环境名-平台-哈希前八位命名一个环境的所有产物放在同一个目录下包括包文件、explicit 清单、.condarc副本、构建脚本、校验和文件。目录一旦定下来就不要改结构因为半年后你会写自动化脚本去扫这些目录。/data/artifacts/20240612-ml-prod-linux64-a1b2c3d4/ ├── ml-prod-20240612.tar.gz # conda-pack 产物 ├── ml-prod-20240612.sha256 ├── explicit-linux64.txt # 精确包清单 ├── wheelhouse/ # pip 轮子 ├── condarc.backup # 客户端配置 └── BUILD.md # 构建说明与已知问题校验和。传输环节的静默损坏比想象中常见尤其是通过 U 盘、内网文件共享这类介质。sha256 校验必须做而且要在解压之前做。校验失败就直接重传不要抱侥幸心理去解压——我见过一次 tar 包尾部损坏导致解压出来的环境缺了几个.so排查了两小时才发现是传输问题。回滚。离线机上新环境上线前先mv老环境到envs/.backup/再部署新的出问题一条mv就回去了。相比就地升级这个习惯救过我至少三次。配合conda env list手动指定envs_dirs也能让 conda 认出这些非标准路径下的环境。6. 现场排查那些报错背后真正的意思6.1 高频故障的定位思路CondaHTTPError: Connection refused或长时间卡在Solving environment。离线机上出现连接类错误八成是没加--offline或者.condarc里还留着远程频道。用conda config --show channels确认一下把所有https://开头的频道删掉再加--offline重试。PackagesNotFoundError: The following packages are not available from current channels。先别怀疑包没下全用conda search --offline -c file:///your-channel pkg直接查。如果搜得到但装不上问题多半在依赖约束上——某个间接依赖的版本区间在频道里找不到匹配。用--info参数看包的所有 build 和依赖声明往往能发现是个python_abi或libgcc-ng的版本卡住了。conda-unpack: command not found。两种情况一是环境没激活二是conda-unpack没被正确打包进bin/。先检查ls /data/envs/xxx/bin/ | grep conda-unpack。如果文件在但还是找不到说明 PATH 没生效用绝对路径执行。ImportError: libxxx.so: cannot open shared object file。这不是 Python 层的问题是动态链接器找不到共享库。用ldd /path/to/xxx.so | grep not found定位缺哪个然后判断是LD_LIBRARY_PATH没设还是包里根本没有这个.so后者常见于 conda-pack 跨机器迁移时某些系统的库被假定存在。ERROR: Could not find a version that satisfies the requirement xxxpip 阶段。离线安装时报这个通常不是 wheelhouse 里没有而是目标 Python 版本和轮子的 ABI 标签对不上。检查pip --version显示的 Python 版本再看 wheelhouse 里文件的命名后缀是不是cp310而目标机是cp39。CondaVerificationError: The package for xxx located at ... appears to be corrupted。sha256 不匹配或者包文件被截断。先conda clean --tarballs清掉这个包再重新从归档里拷一份过来。注意这里的conda clean --tarballs只清压缩包不清解压目录相对安全但离线环境里我仍然建议手工rm指定文件而不是跑 clean。6.2 速查表现象最可能原因快速验证处理装包时卡住不动未启用离线模式conda config --show offline加--offline或设offline: true包搜不到频道里没有该 subdirls /srv/offline-channel/linux-64 | grep 包名补包到正确子目录后重新conda_index环境能激活但命令找不到shebang 路径未修复head -1 envs/x/bin/pip执行conda-unpack二进制导入报 GLIBC 错误打包机 glibc 高于目标机ldd --version对比两端在低版本机重新打包pip 离线装不上ABI 标签不匹配ls wheelhouse | grep cp3用目标机版本重新下载环境体积异常大硬链接被打断du -sh与源端对比用 tar 或cp -a重新传输Windows 打包报文件占用环境处于激活状态看激活项换环境执行conda pack多环境同名包冲突频道优先级非 strictconda config --show channel_priority设为strict这张表我打印贴在机房过后来发现真正用得上的只有前三行但后五行属于遇见一次记一辈子的类型。最后分享一个实际用的技巧在离线机上建一个体检脚本把conda --version、conda config --show channels、conda config --show offline、conda env list、pip --version、pip check这几条的输出全部落到一个日志文件里每部署一台机器跑一次。排查问题的时候先看这份日志能快速排除掉配置没生效这类低级但高发的故障——我遇到过三次明明改了.condarc但没生效原因是同一个用户目录下还有一份优先级更高的配置文件在起作用。
