我太懂这种离线迁移Conda环境的头疼了——之前帮团队迁移生产环境时踩过一模一样的坑，给你几个靠谱的解决方案，按优先级排序：

方法1：用conda-pack直接打包完整环境（最稳妥，零依赖冲突） #

这个工具是Conda官方推荐的离线迁移方案，直接把整个运行中的环境打包成压缩包，到离线机器解压就能用，完全跳过依赖解析和安装步骤，从根源避免冲突问题。

步骤： #

1. 在联网机器上安装conda-pack：

   conda install -c conda-forge conda-pack
   

2. 打包你的目标环境：
   假设你的环境名叫my_env，执行：

   conda pack -n my_env -o my_env.tar.gz
   

   这会生成一个包含环境所有文件的压缩包，包括已安装的所有包、配置和可执行文件。
3. 传输到离线机器：
   用SCP把压缩包传过去：

   scp my_env.tar.gz your_username@offline-machine:/path/to/save/
   

4. 在离线机器上解压并激活环境：
   先创建环境目录（如果你的Conda环境默认路径是~/conda/envs/）：

   mkdir -p ~/conda/envs/my_env
   tar -xzf my_env.tar.gz -C ~/conda/envs/my_env
   

   然后激活环境：

   source ~/conda/envs/my_env/bin/activate
   

   搞定！这个环境和联网机器上的完全一致，不需要任何网络连接。

方法2：修正conda create的离线安装流程（适合不想用额外工具的情况） #

如果你不想用conda-pack，那得调整之前的操作步骤，解决依赖冲突和离线参数的问题：

步骤： #

1. 在联网机器上导出精简版环境配置：
   别用普通的conda env export，它会导出很多冗余的系统依赖和严格的版本号，容易导致冲突。用--from-history参数只导出你手动安装的包：

   conda env export --from-history > my_env_clean.yaml
   

   这个yaml文件会更简洁，只包含你明确安装的包，版本号也更灵活（如果没指定的话）。
2. 打包并迁移Conda包缓存：
   把联网机器的Conda包缓存全部打包，默认路径是~/.conda/pkgs：

   tar -czf conda_pkgs.tar.gz ~/.conda/pkgs/
   

   用SCP把my_env_clean.yaml和conda_pkgs.tar.gz传到离线机器，然后解压缓存到对应路径：

   tar -xzf conda_pkgs.tar.gz -C ~/.conda/
   

3. 用conda create离线创建环境：
   因为conda env create不支持离线参数，我们用conda create配合--offline和--use-local，从精简yaml里提取包名：

   conda create --offline --use-local -n my_env --file <(grep -E '^  - ' my_env_clean.yaml | cut -d' ' -f3)
   

   这个命令会直接从本地缓存读取包，跳过网络请求，而且因为用了精简的包列表，冲突概率会低很多。

额外技巧：强制Conda进入离线模式 #

如果还是遇到Conda偷偷尝试联网的情况，可以设置环境变量强制离线：

CONDA_OFFLINE=true conda create --use-local -n my_env --file <(grep -E '^  - ' my_env_clean.yaml | cut -d' ' -f3)

为什么你之前的方法无效？ #

• conda env create确实不支持--offline/--use-local参数，不加这些参数时，哪怕本地有包，它也会尝试联网校验依赖源，导致失败。
• 直接迁移缓存后用conda create指定所有包，容易因为yaml里的严格版本号、缓存里的冗余包（比如不同版本的依赖）导致兼容性冲突，而--force/--no-deps要么解决不了深层依赖问题，要么会破坏环境完整性。

内容的提问来源于stack exchange，提问作者Xophmeister