主厨老张经营着三家餐厅：A 店做麻辣川菜，B 店主打清鲜粤菜，C 店是法式烘焙。每家店都有自己的独门配方、专用调料和灶台型号。直到有一天，他图省事把所有食材调料全堆进同一个大仓库——结果一锅花椒油泼进粤菜清汤里，老张差点赔掉三块招牌。 这个教训，做 AI 开发的人每天都在经历：项目 A 要 numpy 1.26，项目 B 要 numpy 1.21，全部全局安装会把环境搞成“依赖地狱”，跑着跑着就 ImportError。conda 就是解决这个问题的“中央厨房管理系统”——它为每个项目单独装修一间独立厨房（虚拟环境），各自锁定 Python 版本（灶台型号）和第三方包（食材），互不串味。conda 还内置“食材配送中心”，安装包时自动检查兼容性，保证每道菜口感到位。 本文用一顿饭的功夫，带你走通 conda 从安装、建环境、装包、克隆共享到与 pip 混用的全部流程，从此告别“在我电脑上明明能跑”的尴尬。

岗位关联

对 AI 从业者而言，conda 是机器学习项目可复现、可协作、可部署的“卫生底座”，是数据科学家和算法工程师必备的基础生存技能。

目录
  1. 可视化演示
  2. 环境概念——为什么要分厨房
  3. conda安装——搭建中央厨房系统
  4. 环境创建——装修你的独立厨房
  5. 包管理——中央配送与食材采购
  6. 克隆共享——复制厨房与分享图纸
  7. conda与pip——中央配送与外卖的艺术
  8. 最佳实践——主厨的经营之道
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

\u5c55\u793apip/npm/cargo/go\u7b49\u8bed\u8a00\u5305\u7ba1\u7406\u5668\u7684\u4f9d\u8d56\u89e3\u6790\u4e0e\u5b89\u88c5\u6d41\u7a0b\uff0c\u5305\u542b\u4f9d\u8d56\u6811\u6784\u5efa\u4e0e\u5305\u4ece\u4ed3\u5e93\u5230\u672c\u5730\u7684\u5b89\u88c5\u7ba1\u9053\u3002

本节配有交互动效（进入视口后自动加载，约 3KB）。

\u4f9d\u8d56\u89e3\u6790\u6a21\u5f0f \u6839\u5305app\u5411\u4e0b\u9012\u5f52\u89e3\u6790\u4f9d\u8d56\u6811 \u89e3\u6790\u4e2d\u7684\u8282\u70b9(\u9ec4\u8272\u8109\u51b2) DFS\u6df1\u5ea6\u4f18\u5148\u904d\u5386\u4f9d\u8d56\u56fe

环境概念——为什么要分厨房

花椒油泼进粤菜汤的教训还热气腾腾。现实中，每个 Python 项目就像一家有独家配方的餐厅：目标检测项目要 torch 2.x，Web 服务项目要 flask 4.x，可视化项目要 matplotlib 3.8。它们对食材的需求各不相同，硬塞进一个全局环境，结果就是版本互踩、依赖崩溃。

这种“所有包装在一起”的模式，在产品升级和项目并存时集中爆发：包 A 依赖 numpy<2.0，包 B 却要 numpy>=2.0，任何全局安装都会让其中一方翻车——这就是经典的“依赖地狱”。conda 给出的解药是“环境”：一个环境就是一个独立的包集合空间，各自维护自己的 Python 解释器和第三方库。

用数学的眼光看，一个 conda 环境就是一串“包-版本”对的集合：

集合里的每个元素都绑定一个明确的版本号。安装包就是向集合中加入新元素，卸载包就是移除元素，克隆环境就是把整个集合抄一份。

有了“一间厨房一张清单”的认知，后续操作就顺理成章了：建环境是开新厨房，装包是采购食材，克隆是誊抄清单，删除是整个厨房拆掉。接下来，我们先把中央厨房管理系统——conda 本身——请进门。

E={(p1,v1),(p2,v2),…,(pn,vn)}\displaystyle E = \{(p_1, v_1), (p_2, v_2), \ldots, (p_n, v_n)\}
  1. E 表示环境本身整个独立厨房的完整食材清单，对应一个 conda 虚拟环境。
    E\displaystyle E
  2. 集合的花括号清单中元素的顺序无关紧要，关键在于“有哪些包、各是什么版本”。
    {⋯ }\displaystyle \{\cdots\}
  3. (p_i, v_i) 是包与版本对p_i 是包名，v_i 是版本号，例如 (numpy, 1.26.2)。
    (pi,vi)\displaystyle (p_i, v_i)
  4. 下标 i 与总数 n环境里一共有 n 个包，i 从 1 数到 n，每个包都独一无二。
    i=1,2,…,n\displaystyle i = 1, 2, \ldots, n

conda安装——搭建中央厨房系统

老张决定引入中央管理，第一步是给系统找安身之处。conda 有两种装法：Anaconda 像“全套厨具大礼包”，自带 Python、conda 和几百个常用包，开箱即用但占地几个 GB；Miniconda 像“精简工具箱”，只有核心管理器和少量依赖，食材随用随买。日常学习和数据分析用 Anaconda 省心，服务器和 CI 流水线用 Miniconda 更轻。

安装完成后，conda 需要在系统“命令查找路径”PATH 中注册自己，否则终端敲 conda 会提示 command not found。Windows 安装器会自动写入，macOS/Linux 安装脚本会修改 shell 配置文件。验证安装只需要两条命令：conda --version 看版本，conda info 看环境根目录。从数学上理解 PATH 的更新：

中央厨房管理系统落座后，老张开始给每家餐厅分配独立厨房。接下来就是最常用的操作——创建环境。

PATHnew={conda/bin}∪PATHold\displaystyle \text{PATH}_{\text{new}} = \{\text{conda}/\text{bin}\} \cup \text{PATH}_{\text{old}}
  1. PATH 变量操作系统查找可执行命令的“路口清单”，按顺序逐个目录搜索。
    PATHold\displaystyle \text{PATH}_{\text{old}}
  2. conda/bin 目录conda 可执行文件存放的地方，只有加入 PATH 才能被终端直接找到。
    conda/bin\displaystyle \text{conda}/\text{bin}
  3. 并集符号 ∪在原有路口基础上新增一条，不影响其他已注册命令的查找。
    ∪\displaystyle \cup
  4. 新 PATH 赋值安装器把 conda 目录放到最前面，于是输入 conda 时系统立刻命中。
    PATHnew={conda/bin}∪PATHold\displaystyle \text{PATH}_{\text{new}} = \{\text{conda}/\text{bin}\} \cup \text{PATH}_{\text{old}}

环境创建——装修你的独立厨房

装修厨房前要想清楚：这家店做什么菜？用什么灶台？conda 建环境的核心也就两件事——起名和定 Python 版本。一条命令下去，一间空空如也的厨房就立起来了，后续所有食材都放进去。

conda create -n ml python=3.11 创建名为 ml 的环境并指定 Python 3.11；conda activate ml 激活环境，相当于推门走进这间厨房，此后安装的每个包都只属于它；conda env list 巡视所有后厨，看看有几间厨房；conda env remove -n ml 则整间厨房连同食材一起拆掉。子命令的结构可以抽象为：

门牌挂好后，正式采购就要来了。conda 的“食材配送中心”会帮你把关每个包的兼容性。

conda create  [−n  name]  [spec1,…,speck]\displaystyle \text{conda create} \; [-n \; \text{name}] \; [\text{spec}_1, \ldots, \text{spec}_k]
  1. conda create 子命令告诉 conda 现在要开一间新厨房，最基础的骨架。
    conda create\displaystyle \text{conda create}
  2. -n name 参数-n 后面跟环境名，它相当于厨房的门牌号，后续激活、删除全凭此号。
    −n name\displaystyle -n \ \text{name}
  3. spec 规格列表建厨房时顺带预装的包和版本约束，例如 python=3.11、numpy 都是 spec。
    spec1,…,speck\displaystyle \text{spec}_1, \ldots, \text{spec}_k
  4. 方括号表示可省略规格可以一个都不写，先建空厨房再慢慢采购。
    [spec]\displaystyle [\text{spec}]

包管理——中央配送与食材采购

新厨房开张，第一批食材必须靠谱。conda install numpy pandas 就是向配送中心下单：配送中心先检查这些食材和当前灶台（Python 版本）是否相容，再统一发货。这比老张自己跑菜市场乱买靠谱得多——菜贩（pip）可不管你的灶台型号。

conda install 装包，conda remove 卸包，conda update 升级，conda list 查看当前环境的完整清单。频道（channel）对应不同食材供应商，默认从 main 和 conda-forge 等官方频道配货，可用 -c 指定或写入 .condarc 文件。版本锁定用约束符号表达，让配送中心在指定区间内给你最优解：

采购上瘾也要有节制：清单有个默契——每个包只保留一个版本，装新卸旧，厨房才不会堆成杂物间。当你想把一间调试完美的厨房原样复制给别人时，就该克隆和导出了。

pkg≥l ∧ pkg<u,例: numpy≥1.20, numpy<2.0\displaystyle \text{pkg} \ge l \ \wedge \ \text{pkg} < u, \quad \text{例:} \ \text{numpy} \ge 1.20, \ \text{numpy} < 2.0
  1. pkg 目标包名要安装的包，比如 numpy、pandas、torch。
    pkg\displaystyle \text{pkg}
  2. 下界约束 ≥ l版本不低于某个值，防止食材太老缺少新功能。
    pkg≥l\displaystyle \text{pkg} \ge l
  3. 上界约束 < u版本低于某个值，防止大版本更新破坏兼容性。
    pkg<u\displaystyle \text{pkg} < u
  4. 且符号 ∧上下界同时满足，等价于版本落在左闭右开区间 [l, u) 内。
    ∧\displaystyle \wedge

克隆共享——复制厨房与分享图纸

老张在 A 店调出一套完美配方，想原样复制给 C 店。与其凭记忆一点点摆料，不如直接把厨房整套克隆。conda 的方案同样干脆：conda create --clone ml -n ml-2 一键复制环境；conda env export > environment.yml 把环境“图纸”导出为一个文本文件；对方拿到图纸后 conda env create -f environment.yml，在自己的机器上就能重建一模一样的厨房。

这是团队协作和论文复现的黄金流程：每个人都从同一张图纸施工，结果自然一致。整个链路的映射关系如下：

图纸在手，天下我有。但注意跨平台时 conda 可能找不到完全相同的包构建，yml 里的版本范围写宽松些更稳。接下来要处理一个老张也困惑过的问题：中央配送和外卖到底能不能混用？

Esrc→ export yml→ create -f Edst\displaystyle E_{\text{src}} \xrightarrow{\ \text{export}\ } \text{yml} \xrightarrow{\ \text{create -f}\ } E_{\text{dst}}
  1. E_src 源环境已经被调好的、想要复制的厨房。
    Esrc\displaystyle E_{\text{src}}
  2. export 导出动作把环境内所有包及版本写成一个 yml 文件，相当于画出施工图纸。
    → export \displaystyle \xrightarrow{\ \text{export}\ }
  3. yml 中间文件跨机器传递的“图纸”，记录了房间布局、灶台型号和食材清单。
    yml\displaystyle \text{yml}
  4. create -f 重建动作对方按图纸重新装修，最终得到与源环境等价的新厨房。
    → create -f Edst\displaystyle \xrightarrow{\ \text{create -f}\ } E_{\text{dst}}

conda与pip——中央配送与外卖的艺术

中央配送中心再全也有缺货的时候——有些小众食材只有外卖平台（pip）买得到。聪明的老张定下规矩：能走中央配送（conda）的先走，中央没有的才叫外卖（pip），而且外卖永远送进指定厨房，绝不撒在仓库里。

两者本质区别在于管理的范围：conda 同时管理 Python 解释器、系统库和包（比如 CUDA 工具链），依赖解析覆盖“解释器+包”两层；pip 只管理 Python 包，解析范围小得多。混用铁律有三条：先 conda 后 pip；pip 安装必须在已激活的环境中执行，不要用 sudo pip；若环境已被 pip 弄乱，最可靠的修复是推倒重建。用映射表示两者的域：

混用不是禁止，而是要有章法。老张的厨房在规则下始终干净，你也能做到。最后一节，聊聊经营之道。

conda: Py⊗Pkg→Env;pip: Pkg→Env\displaystyle \text{conda:} \ \text{Py} \otimes \text{Pkg} \to \text{Env}; \quad \text{pip:} \ \text{Pkg} \to \text{Env}
  1. conda 的操作域把 Python 解释器（Py）和第三方包（Pkg）作为整体打包进环境，⊗ 表示两层一起管理。
    Py⊗Pkg→Env\displaystyle \text{Py} \otimes \text{Pkg} \to \text{Env}
  2. pip 的操作域只操作 Python 包这一层，不关心解释器版本，输入明显更单薄。
    Pkg→Env\displaystyle \text{Pkg} \to \text{Env}
  3. 分号分隔两个命题左边是 conda 的规则，右边是 pip 的规则，两者并不等价，不能相互替代。
    A→Env;B→Env\displaystyle A \to \text{Env}; \quad B \to \text{Env}
  4. 箭头 → 的含义箭头的终点都是环境（Env），但 conda 的输入包含解释器，这就是“先 conda 后 pip”的根本原因。
    →Env\displaystyle \to \text{Env}

最佳实践——主厨的经营之道

经营多店的主厨，最终拼的是管理。环境管理同理：好习惯让团队协作顺滑，坏习惯让环境逐渐“腐烂”。老张总结出三条铁律，套用到 conda 上同样适用。

第一条：项目隔离，一个仓库一个环境，绝不跨项目共用，因为共用的那一刻起，依赖就开始互相污染。第二条：命名规范，环境用“项目名-用途”格式（如 ml-lab、web-prod），杜绝 temp1、none 这类无意义门牌。第三条：日常维护，用完的临时环境及时 conda env remove，装不上包时先查频道和版本约束，不要盲目用 pip 覆盖。数理地刻画管理节奏：

老张的店越开越多，但每间厨房清爽整洁、菜单一目了然——这就是环境管理的境界。

Nenv≈Nactive project,命名规则: 项目-用途\displaystyle N_{\text{env}} \approx N_{\text{active project}}, \quad \text{命名规则:} \ \text{项目-用途}
  1. N_env 环境数量环境总数应该与活跃项目数大致对应，不为小实验乱开环境。
    Nenv\displaystyle N_{\text{env}}
  2. 约等号 ≈环境与项目一一对应，但允许少量备份环境存在，所以用约等。
    ≈\displaystyle \approx
  3. N_active project当前仍在迭代开发的项目数，是环境规划的基准线。
    Nactive project\displaystyle N_{\text{active project}}
  4. 命名规则 项目-用途门牌一眼可读，ml-lab 表示机器学习实验室，web-prod 表示 Web 生产环境。
    项目-用途\displaystyle \text{项目-用途}

AI 应用场景

复现 GitHub 开源 AI 项目

阶段：项目环境搭建（训练前准备）

解决的问题：论文或开源仓库的 requirements 常常版本缺失、互相冲突，传统做法是手动逐个 pip install，耗时且错误频出。conda 用 environment.yml 一条命令重建作者当时的完整环境，保证训练脚本开箱即跑。

具体案例：克隆某个目标检测仓库后，执行 conda env create -f environment.yml 并 conda activate mmdet，即可复现原论文在 COCO 数据集上的 baseline 实验，无需花费数小时手工对版本。

团队统一开发环境

阶段：团队协作开发

解决的问题：团队成员 Mac/Windows/Linux 混杂，全局安装的包版本不一致，导致“我这边跑得好好的”成为常态，评测结果无法横向对比。

具体案例：数据科学团队把 environment.yml 纳入代码仓库，CI 流水线和每个成员的开发机都从同一份 yml 建环境，训练和评测结果稳定可比，新人 onboarding 时间从半天压缩到 10 分钟。

训练与生产环境一致性

阶段：模型部署上线

解决的问题：训练用的 conda 环境与推理服务环境不一致时，模型可能出现输出漂移，线上事故难以定位。

具体案例：用 conda env export > deploy.yml 固化线上推理环境，配合 conda-pack 打包整个环境目录，使 GPU 服务器的依赖与训练机严格一致，上线事故率显著下降。

Python 演示

python60 行
import jsonimport os  class MiniConda:    """模拟 conda 环境管理器: 每个环境是一个 JSON 记录的独立空间"""     def __init__(self, root=".mini_conda"):        self.root = root        self.envs_dir = os.path.join(root, "envs")        os.makedirs(self.envs_dir, exist_ok=True)     def create(self, name, python_version):        meta_path = os.path.join(self.envs_dir, name, "conda-meta.json")        if os.path.exists(meta_path):            print("环境已存在:", name)            return        os.makedirs(os.path.dirname(meta_path), exist_ok=True)        with open(meta_path, "w", encoding="utf-8") as f:            json.dump({"name": name, "python": python_version, "packages": {}}, f)        print("创建环境:", name, "python", python_version)     def install(self, name, pkg, version):        meta_path = os.path.join(self.envs_dir, name, "conda-meta.json")        with open(meta_path, "r", encoding="utf-8") as f:            meta = json.load(f)        meta["packages"][pkg] = version        with open(meta_path, "w", encoding="utf-8") as f:            json.dump(meta, f, ensure_ascii=False, indent=2)        print("安装到", name + ":", pkg, version)     def show(self, name):        meta_path = os.path.join(self.envs_dir, name, "conda-meta.json")        with open(meta_path, "r", encoding="utf-8") as f:            meta = json.load(f)        print(meta["name"], "| python", meta["python"],              "| 包:", ", ".join(meta["packages"]))     def clone(self, src, dst):        src_meta = os.path.join(self.envs_dir, src, "conda-meta.json")        with open(src_meta, "r", encoding="utf-8") as f:            meta = json.load(f)        dst_meta = os.path.join(self.envs_dir, dst, "conda-meta.json")        os.makedirs(os.path.dirname(dst_meta), exist_ok=True)        meta["name"] = dst        with open(dst_meta, "w", encoding="utf-8") as f:            json.dump(meta, f, ensure_ascii=False, indent=2)        print("克隆:", src, "->", dst)  if __name__ == "__main__":    conda = MiniConda()    conda.create("ml-lab", "3.11")    conda.install("ml-lab", "numpy", "1.26.2")    conda.create("web-app", "3.9")    conda.install("web-app", "flask", "3.0.0")    conda.clone("ml-lab", "ml-backup")    conda.show("ml-lab")    conda.show("web-app")    conda.show("ml-backup")
目的：用 60 行代码模拟 conda 环境管理核心流程，让你看清“环境即独立空间”的本质。
  1. class MiniConda:迷你中央厨房管理系统的蓝图，封装创建、安装、克隆等方法。
  2. self.envs_dir = os.path.join(root, "envs")每个环境就是一个目录，磁盘上天然隔离。
  3. def create(self, name, python_version)装修新厨房，记录灶台型号（Python 版本）。
  4. json.dump({"name": name, "python": python_version, "packages": {}}, f)厨房档案写入 JSON 文件。
  5. meta["packages"][pkg] = version放入食材并锁定品牌规格（包版本）。
  6. def clone(self, src, dst)读源档案、改门牌、写新档案，一步完成厨房复制。
  7. if __name__ == "__main__":主入口，演示创建、安装、克隆的完整工作流。

常见误区

误区“conda 装包又慢又占空间，我觉得直接用 pip 装不就行了嘛，反正都是装包。”

正解pip 只管理 Python 包，无法管理 Python 解释器版本和 CUDA 等二进制依赖。科学计算项目用 pip 装 torch 往往得自己处理一堆 .dll/.so 问题。正确姿势：用 conda 建环境、定 Python 版本、装基础科学计算栈，pip 只补充 conda 没有的纯 Python 包。

为何常见：新手先接触 pip，因为 pip install 一条命令简单直接，看不出它和 conda 在依赖管理深度上的本质差别。

误区“我就跑几个脚本，包全装系统 Python 里不就行了？搞环境多麻烦。”

正解全局安装等于把所有餐厅的食材堆一个仓库。项目一多，版本冲突必然爆发，且卸载升级还会牵连其他项目。conda 环境只需两条命令就能建好，长远看省下的排错时间远超建环境的时间。

为何常见：小项目阶段依赖少、冲突还没出现，很容易低估环境隔离的价值。

误区“conda install 装不上就 pip install，两个一起上总没问题吧？”

正解混用会让 conda 对环境的配方失去感知——pip 装进去的包不在 conda 的依赖树上，后续 conda install 解析依赖时可能覆盖或破坏它们。铁律是：先 conda 后 pip，能用 conda 的绝不用 pip，装 pip 前先激活目标环境。

为何常见：两条命令都叫 install、行为看起来一样，用户自然想不到背后的解析机制完全不同。

误区“我把 environment.yml 发给同事让他 conda env create -f 一下，怎么到他那儿还报错？”

正解conda env export 会包含本机绝对路径和精确构建号（build），在另一个平台（如 Mac→Windows）上可能找不到对应构建。更稳的做法是手动编写 environment.yml，用版本范围（如 python=3.10、numpy>=1.2）约束依赖，让求解器在目标平台灵活选择。

为何常见：本地执行 create -f 成功了，就认为 yml 是万能的，忽略了跨平台构建差异。

误区“我每个小实验都建一个环境，反正磁盘大，这样最安全。”

正解环境太多会带来磁盘浪费和管理混乱（记不清哪个环境装了啥）。正确原则是：每个活跃项目一个环境，用完即删；用 conda env list 定期盘点，用 conda env remove -n 清理不用的环境。

为何常见：尝到隔离的甜头后容易矫枉过正，把环境当成万能保险，忽略了维护成本。

面试题

Q1. conda 环境的核心作用是什么？

单选题 · easy

  • A.加快 Python 程序运行速度
  • B.完全替代 pip 安装工具
  • C.隔离项目依赖避免冲突← 正确答案
  • D.自动生成项目文档内容

答案：C。conda 环境的本质是独立的包集合空间，核心价值是把不同项目的依赖隔离开，避免版本冲突，C 正确。A 涉及性能与解释器实现无关；B 措辞过于绝对，conda 替代不了 pip 的全部生态；D 与文档生成无关。

Q2. 创建名为 tf 且 Python 版本为 3.11 的环境，正确的命令是？

单选题 · easy

  • A.conda create -n tf python=3.11← 正确答案
  • B.conda env create -f tf.yml
  • C.conda new env tf with python
  • D.conda init -n tf python=3.11

答案：A。conda create 是标准创建子命令，-n 指定环境名，后跟 python=3.11 指定解释器版本，A 正确。B 用 env create 时需要的是 yml 文件；C 中 new 不是 conda 子命令；D 的 init 用于初始化 shell 而非建环境。

Q3. 激活名为 ml 的环境，正确的命令是？

单选题 · easy

  • A.conda start ml
  • B.conda activate ml← 正确答案
  • C.conda switch ml
  • D.conda use env ml

答案：B。conda activate 是现代 conda 的标准激活命令，B 正确。A 的 start、C 的 switch、D 的 use 都不是 conda 的合法子命令。激活后命令行前缀会出现环境名，后续安装的包都进入该环境。

Q4. conda 与 pip 混用时的推荐原则是？

单选题 · mid

  • A.全部用 pip 安装速度快
  • B.全部用 conda 不装 pip
  • C.先 conda 后 pip 双管齐下← 正确答案
  • D.只用 pip 但加镜像源

答案：C。推荐“先 conda 后 pip”：先用 conda 管理 Python 解释器和核心科学计算包，再补装 conda 没有的纯 Python 包，C 正确。A、D 完全依赖 pip 会丢失解释器和二进制依赖管理；B 过于绝对，conda 生态覆盖不了所有包。

Q5. conda env export 导出的 environment.yml 中包含什么？

单选题 · mid

  • A.项目全部源代码和注释
  • B.环境的包名和版本列表← 正确答案
  • C.项目自动化测试报告
  • D.环境磁盘空间统计

答案：B。conda env export 输出当前环境的包名、版本号及构建信息，B 正确。A 是代码仓库的内容，与导出无关；C 是测试工具的输出；D 的磁盘统计由 conda info 等命令查看，不在 yml 中。

Q6. 将环境 backup 克隆为新环境 dev 的命令是？

单选题 · mid

  • A.conda clone from backup to dev
  • B.conda copy backup env to dev
  • C.conda create --clone backup -n dev← 正确答案
  • D.conda env duplicate backup dev

答案：C。conda create --clone 后跟源环境名，-n 指定新环境名，C 正确。A 的 clone 不是独立子命令；B 的 copy、D 的 duplicate 都不是 conda 命令。克隆会复制包列表和版本，但不会复制环境内的手工修改文件。

Q7. 关于 conda 环境的说法，正确的是？

多选题 · mid

  • A.不同环境可有不同 Python 版本← 正确答案
  • B.删除环境会删除其中所有包← 正确答案
  • C.所有环境共享一个解释器
  • D.克隆会复制包及其版本← 正确答案

答案：ABD。每个 conda 环境都有独立的 Python 解释器，创建时可指定版本，A 正确、C 错误。conda env remove 会连同环境内所有包一并删除，B 正确。克隆本质是复制包集合和版本信息，D 正确。

Q8. 最适合用 conda 管理的场景是？

单选题 · hard

  • A.安装纯 JavaScript 第三方库
  • B.科学计算栈与二进制依赖← 正确答案
  • C.编辑 Markdown 格式文档
  • D.配置 Git 用户名和邮箱

答案：B。conda 擅长管理带二进制依赖的科学计算栈（如 torch 依赖 CUDA 动态库），B 正确。A 用 npm 管理；C 是文本编辑问题；D 用 git config 命令，三者都不是包管理范畴。

Q9. 正确共享 conda 环境给他人的方式有？

多选题 · hard

  • A.导出 environment.yml 给对方← 正确答案
  • B.压缩发送本机环境目录
  • C.发送 pip freeze 输出结果
  • D.对方用 yml 重建新环境← 正确答案

答案：AD。标准流程是导出 yml（A）让对方 create -f 重建（D），A、D 正确。B 直接拷贝环境目录常因本机绝对路径、符号链接导致跨机失败；C 的 pip freeze 缺 Python 版本和 conda 包信息，信息不完整。

Q10. 关于 conda 与 pip 的依赖解析差异，正确的是？

多选题 · extreme

  • A.conda 统一解析 Python 解释器版本← 正确答案
  • B.conda 提供预编译二进制包← 正确答案
  • C.pip 能解析非 Python 系统依赖
  • D.混用时先 conda 后 pip 更安全← 正确答案

答案：ABD。conda 的求解器把解释器（如 python=3.11）和包一起纳入约束，A 正确；conda 包是打包好的二进制（含 .so/.dll），无需本地编译，B 正确；混用先 conda 后 pip 可保护 conda 依赖树不被破坏，D 正确。C 错误——pip 只解析 Python 包间的依赖，无法处理 CUDA 等系统级二进制依赖。