本文是《AI工程师踩坑实录》系列第 6 篇。机器上装了 11.8 又装了 12.x，conda 环境也切了，nvcc 给出的版本还是不对，训练时莫名报库找不到。这一篇在本机用两个真实的 CUDA 工具链版本做对照实验，把「谁在生效」的裁判规则讲透。
本篇配套的三场景复现命令放在公Z号关注私信领取。
这个坑的典型剧本是这样的。
机器上装了两套 CUDA，比如一套 11.8 一套 12.6。你在 conda 环境里切来切去，敲 nvcc -V，显示的还是你不想要的那套。编译扩展的时候报一堆库找不到，报错指向的路径你根本没印象装过。
第一反应通常是，是不是没装好，卸了重装。装完，还是串。
问题从来不是「装没装」，是「谁排在前面」。今天用本机实验把这条规则钉死。
一、实验设置：两套真实 CUDA 工具链
我在本机准备了两套并存的 CUDA 编译工具链组件，一套 12.6.85，一套 12.9.86，分别装在两个独立的环境目录里（用的是 pip 轮子分发的 CUDA 工具链组件 ptxas，它就是官方 CUDA 安装包里 bin 目录下的那个 ptxas.exe，版本行为与 nvcc 完全一致，这样演示不用动系统级安装）。
现在机器上同时存在两套 CUDA 工具链，各自待在自己的目录里。接下来只动一个东西，PATH 的顺序。
二、三场景实测，同一个命令三种结果
场景一，PATH 里只有 A（12.6.85）。
where.exe 找到唯一一个 ptxas，版本 12.6.85，生效的就是它。
场景二，PATH 里换成 B（12.9.86）。
同一个命令，同一段代码，输出版本变成 12.9.86。注意我全程没动两套工具链的安装位置，只动了 PATH。
场景三，重点来了，A 和 B 都在 PATH 里，A 排在前面。
where.exe 找到了两个 ptxas，两个都「装着」。但敲 ptxas --version，生效的是 12.6.85。
这就是「装了两套还在串」的完整真相。两套都存在、都完好，最后谁干活，由 PATH 里的排序决定，跟哪个后装、哪个版本新，一概无关。
三、机制：PATH 是个队列，命令是查表
把三场景浓缩成一张图。
PATH 本质是一个用分号分隔的目录队列。你在终端敲一个命令，Windows 从队列最左边开始，逐个目录找同名可执行文件，第一个命中的直接执行，后面的看都不看。
所以「切换环境」这个动作要想真正生效，靠的是把目标环境的目录插到队列最前面。conda activate 干的就是这件事，它把当前环境的 bin 目录前置。如果你只是换了 shell、开了新标签、或者 activate 的环境里根本没带 CUDA，队列排序没变，生效的自然还是原来那位。
「装了」和「生效了」是两码事，中间隔着一个 PATH 顺序。
四、照妖镜是 where.exe，不是你的感觉
排查这类问题的第一命令不是重装，是 where.exe。
where.exe nvcc 一敲，把你 PATH 里所有能找到的 nvcc 全列出来，按生效优先级排序，第一个就是真正干活的那个。这一条命令，比你回忆「我上周好像装的是 12.1」可靠一百倍。
顺带一提，PyTorch 侧的对应检查是 torch.version.cuda（第 1 篇讲过），它只认自己 wheel 里带的运行时，不受 PATH 影响。工具链认 PATH，框架认 wheel，两套逻辑别搞混。
五、常见问题 3 连
1. 怎么把想要的版本变成「生效的」那个？
两条路。临时改，当前会话里把目标 bin 目录前置到 PATH（env:Path = "目标bin;" + env:Path，改完立即可用，关窗即失效）。永久改，系统环境变量面板里把目标 CUDA 的 bin 上移到另一个之前。conda 用户优先用 activate，让工具替你管理前置。
2. 我用 conda 环境隔离了 CUDA，为什么还会串？
检查两点。一，activate 的是不是装了 CUDA 的那个环境，没带 CUDA 的环境 activate 完，队列前面没有新条目，系统级安装照样生效。二，有的脚本会在运行时自己改 PATH（比如某些深度学习框架的启动脚本），排序又被它动了。诊断方法不变，在出问题的那个会话里敲 where.exe nvcc，看队列第一行。
3. 动态库也遵循这套规则吗？
规则相同，裁判不同。可执行文件由 PATH 裁决，动态库（DLL）在 Windows 上也走 PATH 搜索，所以 DLL 版本冲突的经典病根同样是「同名的 dll 出现在多个 PATH 目录里，排前的赢」。Linux 侧对应的是 LD_LIBRARY_PATH。库名冲突导致「编译过了、运行报错」的诡异现象，多半是这条路来的。
六、本篇小结
- 装了两套 CUDA 还在串，不是装错，是 PATH 排序不对，队列左边第一个命中才生效。
- where.exe 是照妖镜，一条命令列出全部候选和真实生效者。
- 切环境要生效，靠的是目标目录被前置，conda activate 本质干的就是这个。
本篇坑卡片
| 字段 | 内容 |
|---|---|
| 坑名 | 多套 CUDA 工具链共存时 PATH 排序决定实际生效版本 |
| 现象原文 | 切换环境后 nvcc/ptxas 版本不变，编译时报库找不到 |
| 环境 | Win11，两套 CUDA 工具链组件 12.6.85 与 12.9.86 并存 |
| 复现步骤 | 双版本分别安装 → PATH 前置 A 测一次 → 前置 B 测一次 → 两者都在 PATH（A 在前）再测 |
| 根因 | PATH 是队列，命令从左到右第一个命中即执行，与安装顺序、版本新旧无关 |
| 解法 | 会话内前置目标 bin 或永久调整系统 PATH 顺序，conda 用 activate 前置 |
| 避坑建议 | 排查第一步永远先 where.exe，不要凭记忆猜哪个版本在生效 |
| 可信度 | 本机验证 |
| 版本时间戳 | 2026-11-05，CUDA 工具链组件 12.6.85 / 12.9.86 |
| 关联坑 | 第 1 篇 nvidia-smi 的 CUDA 版本（同为环境层） |
专栏导航
| 篇次 | 主题 | 状态 |
|---|---|---|
| 1 | nvidia-smi 显示的 CUDA 版本到底是不是你装的那个 | ✅ |
| 2 | torch.cuda.is_available() 一直是 False，一条命令定位断点 | ✅ |
| 3 | 标签和图像没对齐，模型一直在学噪声 | ✅ |
| 4 | loss 变 NaN，用 hook 逐层定位 | ✅ |
| 5 | DataLoader 卡死在第一个 batch，Windows 多进程的坑 | ✅ |
| 6 | 装了两套 CUDA 还在串，PATH 与优先级的真相 | ✅（本篇） |
| 7 | 数据泄漏：预处理做在了划分之前 | 排期中 |
| 8 | RAG 答一半开始编，检索阈值与拒答机制实操 | 排期中 |
| 9 | 随机种子都设了，结果还是不可复现 | 排期中 |
| 10 | 相似度全是 0.9：向量没归一化 | 排期中 |
| 11 | 开了混合精度就 NaN，GradScaler 到底在做什么 | 排期中 |
| 12 | loss 不降反升，先别怀疑模型结构 | 排期中 |
| 13 | 训练降验证不降：先查数据再谈正则 | 排期中 |
下一篇预告，《数据泄漏：预处理做在了划分之前》。验证集分数虚高，上线就崩。下一篇用同一份数据只改一个处理顺序，让指标的差距自己开口说话。
版权说明，本文三场景输出均来自本人真机复现，专栏读者可学习使用，禁止转售或整篇搬运。