我已经不是第一次干这种"别人升级我降级"的事了。Ubuntu 22.04 装好之后，系统自带源里给的 CUDA 已经是 12.x 系列，但手上几个深度学习项目、同事分享的推理代码、还有某个得用老版本 TensorFlow 才能跑通的模型，全都指向 CUDA 11.3。于是问题来了：怎么在 Ubuntu 22.04 上把 CUDA 降级装成 11.3？这条路看似简单，实际走起来全是兼容性坑——GCC 版本太新、驱动版本不匹配、apt 源里找不到老包、新显卡和老 CUDA 打架。这篇就完整记录我踩完坑之后的最终方案和排错思路，给同样被 CUDA 11.3 卡住的人一条能直接抄的路径。

1. 为什么会碰到这个问题：Ubuntu 22.04与CUDA 11.3的适配现状

1.1 什么场景下必须降级到CUDA 11.3

先说结论：不是所有人都需要降级。如果你是新项目、新框架、新显卡，直接用 CUDA 12.x 完全没问题。但下面这几类场景，你大概率会被迫回到 CUDA 11.3：

• 老版本深度学习框架：TensorFlow 2.5~2.9 这一批版本里，官方预编译包基本对应 CUDA 11.2/11.3。尤其是 TensorFlow 2.8.0 这种中间版本，官方文档明确写着推荐 CUDA 11.2 和 cuDNN 8.1，但很多人实测下来 11.3 也能跑得很稳。PyTorch 这边，torch 1.10.0 和 1.11.0 的 cu113 轮子一大把人在用。
• 自动驾驶/机器人项目：Autoware、某些基于 CUDA 的感知模块，代码里写死了 CUDA 11.3 的算子库接口。升到 12.x 后 ABI 不兼容，编译期报一堆函数找不到。
• Numba 和 numba-cuda 生态：Numba 0.55 左右版本对 CUDA 11.3 支持得比较好，到了 0.58 之后开始全面转向 CUDA 12。如果你的 CUDA Python 代码还停留在老 API，升上去就得改代码。
• 公司内部依赖：团队里其他人都在用 CUDA 11.3 编译的算子库，你一个人升到 12.x，发过来的 .so 或 .pt 文件直接用不了，这种协作层面的锁死往往比技术层面的更无解。

所以降级不是技术洁癖，是现实需求。而 Ubuntu 22.04 是当前很多人新装系统时的默认选择，这才导致"新系统 + 老 CUDA"这种看似拧巴的组合频繁出现。

1.2 Ubuntu 22.04 默认环境与老 CUDA 的冲突点

Ubuntu 22.04 和 CUDA 11.3 之间隔了快一年的发布周期，系统里的默认组件已经全面"更新"了。核心冲突有四个：

第一个是GCC 版本。Ubuntu 22.04 默认的 gcc 是 11.2，而 CUDA 11.3 官方支持的 GCC 最高到 10.x。用 nvcc 编译时直接报"unsupported GNU version"错误。需要注意：如果你只是跑别人编译好的程序或者 pip 安装的 PyTorch，GCC 版本无所谓；但只要涉及本地编译 CUDA 扩展（比如某些 GitHub 项目需要 build from source），GCC 就得降到 10。

第二个是显卡驱动。Ubuntu 22.04 的 apt 源里默认推荐的是 nvidia-driver-535 或更新的版本，这些新驱动本身是支持老的 CUDA runtime 的（NVIDIA 驱动向后兼容做得不错），但问题在于很多人根本不知道驱动和 CUDA 版本之间的对应关系，装完新驱动就以为万事大吉，结果跑程序时报"driver version is insufficient"。

第三个是cuDNN。CUDA 11.3 对应的 cuDNN 是 8.2.x 版本。Ubuntu 22.04 源里的 cuDNN 版本比较新，和 CUDA 11.3 对不上。这个坑往往藏得很深，因为 cuDNN 装错版本不会像驱动错误那么直接报出来，而是运行到卷积层时出现莫名其妙的崩溃或精度问题。

第四个是内核版本。Ubuntu 22.04 默认内核 5.15，也可以通过 HWE 更新到更新的内核。CUDA 11.3 发布时主要是针对 Ubuntu 20.04（内核 5.4/5.8/5.11）做的验证，理论上内核 5.15 也能跑，但如果驱动版本太老（比如 470 之前），在新内核上编译 DKMS 模块容易失败。

这四个冲突点基本就是降级路上 80% 的坑，提前认识了，后面就从容得多。

2. 兼容性摸底：驱动、GCC、内核与CUDA版本的对应关系

2.1 显卡驱动与CUDA版本的最低对应表

在没有显卡驱动的情况下直接装 CUDA Toolkit 是可以装上的，但一个程序都跑不起来。驱动和 CUDA 的版本关系决定了后面所有操作的可行范围。

这里有个非常重要的原则：驱动向后兼容，但向前不兼容。也就是说，新版本的驱动能跑旧版本的 CUDA Toolkit，但旧版本的驱动跑不了新版本的 CUDA。所以如果你想装 CUDA 11.3 并且用的是 RTX 3090/3080 这类 Ampere 显卡，装一个 470 或 495 的驱动就很好；如果你用的是 RTX 4060 这类 Ada 架构显卡，那就必须装 535 甚至更新的驱动才能识别显卡，好在 535 驱动完全兼容 CUDA 11.3 的 runtime。

用nvidia-smi能看到当前驱动版本和支持的最高 CUDA 版本：

nvidia-smi

输出里右上角显示的就是驱动版本，下面表格显示"CUDA Version"，这个数字只代表当前驱动最高支持到哪个 CUDA 版本，跟你实际装的 CUDA Toolkit 是两回事。很多人看到这里显示 12.2 就以为系统里的 CUDA 是 12.2，其实只是驱动支持而已，这是个高频误区。

2.2 GCC版本：nvcc 编译能否通过的关键

CUDA 11.3 的 nvcc 对 GCC 的版本有硬性检查。官方支持的最高版本是 GCC 10，如果你用默认的 GCC 11 直接编译，会看到这样的错误：

ERROR: Unsupported gcc version! gcc version 11.2.0 is not supported

解决方法不是把 GCC 卸载，而是安装 GCC 10 然后用 update-alternatives 做版本切换，这样两个版本共存，系统默认还是 11，只有需要编译 CUDA 代码时切到 10：

sudo apt install gcc-10 g++-10 sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-11 110 sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-10 100 sudo update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-11 110 sudo update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-10 100 # 查看当前配置 sudo update-alternatives --config gcc sudo update-alternatives --config g++

切到 gcc-10 后，再执行gcc --version确认一下。如果你有 conda 环境，也可以在 conda 里装一个 gcc_linux-64 的老版本，只影响当前虚拟环境，不污染系统。这个思路在多项目开发时更安全。

2.3 内核版本：其实不是最大的拦路虎

很多人一听内核版本就觉得完蛋了，其实 CUDA Toolkit 本身和内核的关系很小——它提供的是用户态库和编译器，内核只跟 NVIDIA 驱动有关。换句话说，内核 5.15 或 6.2 都可以跑 CUDA 11.3，只要驱动能正常加载。

驱动这一层如果出现编译问题，优先检查 DKMS 日志：

sudo dkms status cat /var/log/dkms/*.log

如果看到编译失败的记录，大概率是驱动版本和内核头文件不匹配。解决方式是安装对应的 linux-headers：

sudo apt install linux-headers-$(uname -r)

然后重新安装或重新编译驱动。只要驱动能加载，nvidia-smi能正常显示，CUDA 11.3 就不会跟内核有直接冲突。

3. 驱动先行：装一块能让CUDA 11.3正常工作的NVIDIA显卡驱动

3.1 第一步先确定显卡型号与驱动策略

动手前必须搞清楚你手里的是什么卡。不同的卡决定了驱动选型的边界：

lspci | grep -i nvidia

如果输出是NVIDIA GA102 [GeForce RTX 3080]这类 Ampere 架构，用 470 或更新的驱动都合适。如果输出是NVIDIA AD106 [GeForce RTX 4060]这类 Ada 架构，则必须装 535 系列或更新的驱动。Ada 架构的卡强行装老驱动会出现无法识别显卡、黑屏或无显示输出。

驱动安装方式主流有三种，我按推荐程度排：

从"降级装 CUDA 11.3"这个目标来看，apt 源里装 535 或 545 是最省事的，因为新驱动兼容老 CUDA 完全没问题。但如果你需要离线安装，runfile 就是最稳的路径，热搜里"离线安装nvidia显卡驱动"这个需求也是这么来的。

3.2 runfile方式安装驱动的完整流程（含离线场景）

先说离线场景。你需要在有网络的环境下，先从 NVIDIA 官网下载对应驱动跑文件，比如：

wget https://us.download.nvidia.com/XFree86/Linux-x86_64/535.154.05/NVIDIA-Linux-x86_64-535.154.05.run

然后把这个 .run 文件通过 U 盘等方式带到目标机器。执行安装之前，先处理 nouveau 驱动和图形界面的干扰：

# 禁用nouveau sudo bash -c "echo 'blacklist nouveau' >> /etc/modprobe.d/blacklist-nvidia-nouveau.conf" sudo bash -c "echo 'options nouveau modeset=0' >> /etc/modprobe.d/blacklist-nvidia-nouveau.conf" # 更新initramfs sudo update-initramfs -u # 重启并进入文本模式（Server版跳过） sudo systemctl set-default multi-user.target # 临时关图形界面 sudo reboot

重启后确认 nouveau 没加载，然后执行驱动安装：

sudo sh NVIDIA-Linux-x86_64-535.154.05.run --silent --dkms

加上--dkms参数非常重要，这样的话内核每次升级后驱动能自动重新编译，不然一升级内核你的显卡驱动就挂了，又得重来一遍。装完重启，回到图形界面：

sudo systemctl set-default graphical.target sudo reboot

验证驱动是否安装成功：

nvidia-smi

出现类似下面输出就说明驱动正常了：

+-----------------------------------------------------------------------------+ | NVIDIA-SMI 535.154.05 Driver Version: 535.154.05 CUDA Version: 12.2 |

这里再次强调，右上角 CUDA Version 12.2 只是驱动支持的最高 CUDA 版本，不代表你本地已经装了 CUDA 12.2，后续装 CUDA 11.3 完全没问题。

3.3 在线环境更省事的替代方案

有条件联网的机器，我其实更推荐直接用 apt 装官方源里的驱动，省去签名、nouveau 这些麻烦：

sudo apt update sudo apt install ubuntu-drivers-common sudo ubuntu-drivers devices

这个命令会列出当前推荐的驱动版本。装显卡对应的推荐版本即可：

sudo apt install nvidia-driver-535 sudo reboot

在线装完之后同样用nvidia-smi验证。你可能会注意到 apt 装完的驱动版本比官网下载的要低一两个小版本，但满足 CUDA 11.3 的需求绰绰有余。

4. runfile与deb的取舍，以及两步完成CUDA 11.3降级安装

4.1 为什么我推荐 runfile 而不是 deb

CUDA Toolkit 的安装方式有两种主流选择，我用一张表说清楚差异：

在 Ubuntu 22.04 上装 CUDA 11.3 有一个天然问题：官网的 CUDA 11.3 下载页只提供 Ubuntu 20.04 的选项，没有 Ubuntu 22.04 的。这时候 deb 方式会遇到依赖检查问题，因为某些依赖包的版本和 Ubuntu 22.04 不完全兼容，虽然可以加--allow-downgrades/--allow-change-held-packages强行装，但容易搞得一团糟。runfile 方式就完全没有这个问题，它只做文件解压和路径配置，不经过 apt 依赖检查，所以强烈建议 runfile。

4.2 下载并执行 CUDA 11.3 的 runfile 安装

CUDA 11.3 的官方下载在 NVIDIA 的 archive 页面，直达地址是：

wget https://developer.download.nvidia.com/compute/cuda/11.3.0/local_installers/cuda_11.3.0_465.19.01_linux.run

注意文件名里的465.19.01是自带驱动的版本。我们会用 runfile 里的工具安装，但不会装它自带的驱动（因为驱动已经装好了，再装一个旧驱动反而把事情搞复杂）。

执行安装前建议先看一下帮助选项：

sh cuda_11.3.0_465.19.01_linux.run --help

然后开始安装：

sudo sh cuda_11.3.0_465.19.01_linux.run --silent --toolkit --toolkitpath=/usr/local/cuda-11.3 --no-opengl-libs

拆解一下参数含义：

• --silent：无人值守模式，不会弹交互界面，适合远程终端。
• --toolkit：只装 Toolkit，不装 Driver。这一步就是"降级"的核心，我们要保留已经装好的新驱动，不要被自带的老驱动覆盖。
• --toolkitpath=/usr/local/cuda-11.3：指定安装目录。这个路径要显式指定，方便后续多版本共存管理。
• --no-opengl-libs：不加这一项的话在某些桌面环境下可能导致循环登录或者黑屏，我吃过这个亏，所以每次必加。

如果你希望带交互界面装，也可以不加--silent，进入菜单后操作方式：在第一个界面选Options，然后取消Driver勾选，再返回把CUDA Toolkit勾上，Install 即可。两种方式结果一样，这里看自己习惯。

安装完成后，检查目录结构：

ls /usr/local/cuda-11.3

正常情况下应该能看到 bin、lib64、include、nvvm 等目录。

4.3 环境变量与软链接配置

装好之后，系统还不知道去哪里找 cuda-11.3。这里有两种配置思路：

第一种是直接修改用户环境变量，在~/.bashrc末尾追加：

export PATH=/usr/local/cuda-11.3/bin:$PATH export LD_LIBRARY_PATH=/usr/local/cuda-11.3/lib64:$LD_LIBRARY_PATH export CUDA_HOME=/usr/local/cuda-11.3

然后source ~/.bashrc。这种方式简单直接，但缺点是一旦以后装了多个 CUDA 版本，切来切去要反复改这个文件。

第二种是使用/usr/local/cuda软链接作为统一入口，环境变量只指向软链接路径，以后切换版本只需要改软链接。这是目前多版本共存的普遍做法：

sudo rm -f /usr/local/cuda sudo ln -s /usr/local/cuda-11.3 /usr/local/cuda

然后在~/.bashrc里配置：

export PATH=/usr/local/cuda/bin:$PATH export LD_LIBRARY_PATH=/usr/local/cuda/lib64:$LD_LIBRARY_PATH export CUDA_HOME=/usr/local/cuda

这样以后装了 cuda-12.x，只需要把软链接一改，环境变量不用动，相关的 CMake 工程和 PyTorch 编译都能正常识别。我想大部分人装完 CUDA 11.3 之后不会只用这一个版本，所以强烈建议按第二种方式配置。

4.4 验证一下版本号

配置完环境变量后，新开一个终端或重新 source，执行：

nvcc -V

看到类似输出：

nvcc: NVIDIA (R) Cuda compiler driver Copyright (c) 2005-2021 NVIDIA Corporation Built on Sun_Feb_14_21:12:02_PST_2021 Cuda compilation tools, release 11.3, V11.3.58

这一步出来Cuda compilation tools, release 11.3, V11.3.58，你的 CUDA 降级安装就已经成功了一大半。

5. 多版本CUDA共存：切换管理的三个层面

5.1 为什么不要只装 11.3 一个版本

有个观点我需要先纠正：CUDA 降级不等于"卸载新版本只留老版本"。通常我不会把系统里已有的 CUDA 12 删掉，因为 Ubuntu 22.04 很多应用和编译链可能依赖新版本，而且有些新卡（比如 40 系）在 CUDA 11.3 下的支持不完整。保留多版本，按项目需求切换，才是工程上更合理的选择。

实际项目里，你会同时遇到"这个仓库要用 CUDA 11.3"和"那个新框架需要 CUDA 12.x"的情况。如果每次切换都重装系统或者卸载重装，那时间就全耗在环境上了。所以多版本共存不是可选项，是刚需。

5.2 软链接方式：最直接的切换逻辑

前面提到用软链接管理/usr/local/cuda，这里把切换脚本化：

# 切换到 CUDA 11.3 sudo rm -f /usr/local/cuda sudo ln -s /usr/local/cuda-11.3 /usr/local/cuda # 切换到其他版本（假设你装了 cuda-12.3） sudo rm -f /usr/local/cuda sudo ln -s /usr/local/cuda-12.3 /usr/local/cuda

由于环境变量里指向的都是/usr/local/cuda这个软链接，所以切换后不需要改~/.bashrc。核心就一句话：软链接指到哪个版本，nvcc 就是哪个版本。

实际维护中，我会用一个小脚本放到~/bin/switch-cuda.sh：

#!/bin/bash if [ -z "$1" ]; then ls -la /usr/local/ | grep cuda echo "Usage: switch-cuda.sh <version>" exit 1 fi if [ -d "/usr/local/cuda-$1" ]; then sudo rm -f /usr/local/cuda sudo ln -s "/usr/local/cuda-$1" /usr/local/cuda echo "Switched to CUDA $1" else echo "CUDA $1 not found in /usr/local" fi

用法：

chmod +x ~/bin/switch-cuda.sh ~/bin/switch-cuda.sh 11.3 nvcc -V

这样每个项目开头source一次或手动切一次，不会互相污染。

5.3 update-alternatives：另一种管理思路

如果你更喜欢滚轮式切换而不是手动 ln，也可以使用 update-alternatives 来管理：

sudo update-alternatives --install /usr/local/cuda cuda /usr/local/cuda-11.3 113 sudo update-alternatives --install /usr/local/cuda cuda /usr/local/cuda-12.3 123 # 切换 sudo update-alternatives --config cuda

这个方式会让系统维护一个候选列表，每次切换只需要记住一个命令。但说实话，我觉得这个方式对大多数场景来说过于重量级，配置的优先级数字容易让人困惑，不如软链接脚本直观。这里写出来是让你知道有这条路，根据自己的习惯选择就好。

5.4 多版本环境最容易忽略的库路径陷阱

软链接切换只是切了编译器，有个地方常常漏掉：运行时库的缓存。即使LD_LIBRARY_PATH配好了，系统还有一层/etc/ld.so.conf.d/下的配置和ldconfig缓存。某些程序在加载libcudart.so时会先去 ldconfig 缓存里找，如果缓存还指向老版本路径，就会出现" nvcc 显示 11.3 但运行的程序用的还是 12.x"这种诡异情况。

解决办法是检查并更新 ld 配置：

ls /etc/ld.so.conf.d/

如果你发现里面有cuda-11-3.conf或类似文件，说明安装时已经自动注册过了。手动更新缓存：

sudo ldconfig ldconfig -p | grep cudart

这一步能帮你排查很多"版本切换了但程序还是调用旧库"的问题。建议每次切换完 CUDA 版本后，都顺手执行一次sudo ldconfig，几秒钟的事，能挡掉后面一个小时的排查。

6. 验证安装和排错记录：nvcc已经就绪，但程序跑不起来怎么办

6.1 从 nvcc 到能跑深度学习程序之间的验证链路

很多人做到nvcc -V就以为结束了，其实那只是第一步。一条完整的验证链路应该是：

# 编译并运行设备查询示例 cd /usr/local/cuda-11.3/samples/1_Utilities/deviceQuery sudo make clean && sudo make ./deviceQuery

如果末尾出现Result = PASS，说明显卡驱动和 CUDA Toolkit 的配合是正常的。再跑一个带宽测试：

cd /usr/local/cuda-11.3/samples/1_Utilities/bandwidthTest sudo make && ./bandwidthTest

Result = PASS说明内存读写路径正常。这两个示例程序是 NVIDIA 官方自带的最基础冒烟测试，建议装完必跑。

如果你的最终目的是跑 PyTorch，那接下来最重要的是确认 PyTorch 的轮子是不是对应 CUDA 11.3：

python -c "import torch; print(torch.__version__); print(torch.version.cuda); print(torch.cuda.is_available())"

如果输出torch.version.cuda是 11.3 且torch.cuda.is_available()是 True，那么你的环境基本就绪了。安装对应版本的方式是：

pip install torch==1.11.0+cu113 torchvision==0.12.0+cu113 torchaudio==0.11.0 --extra-index-url https://download.pytorch.org/whl/cu113

注意 PyTorch 版本要和你的项目需求匹配，这里只是举例。

6.2 常见错误对照表与解决组合拳

我在降级过程中实际遇到、以及帮别人排查过的常见错误，汇总如下：

这里面最坑的是最后一条，因为 conda 环境有时候会设置自己的LD_LIBRARY_PATH，覆盖系统配置。运行前可以用：

echo $LD_LIBRARY_PATH

确认路径里确实包含/usr/local/cuda-11.3/lib64。

6.3 cuDNN 的版本对应问题

CUDA 11.3 配套的 cuDNN 是 8.2.x。很多人只降级 CUDA 但忘了降 cuDNN，导致训练时在卷积层报错，这类错误通常没有明显的版本提示，而是表现为莫名的精度异常或崩溃。

cuDNN 的安装方式推荐用 .deb 或 tar 包。下载需要 NVIDIA Developer 账号，选择cuDNN v8.2.4 for CUDA 11.3 (x86_64)即可。tar 方式解压后把文件复制到 CUDA 目录：

tar -xzvf cudnn-11.3-linux-x64-v8.2.4.15.tgz sudo cp cuda/include/cudnn*.h /usr/local/cuda-11.3/include/ sudo cp cuda/lib64/libcudnn* /usr/local/cuda-11.3/lib64/ sudo chmod a+r /usr/local/cuda-11.3/include/cudnn*.h /usr/local/cuda-11.3/lib64/libcudnn*

然后执行sudo ldconfig刷新缓存，再用：

cat /usr/local/cuda-11.3/include/cudnn_version.h | grep CUDNN_MAJOR -A 2

确认版本号。这一步在深度学习场景下几乎必做，千万别跳。

6.4 关于"ubuntu22.04和4060不兼容"这类传言的真相

最近总看到"Ubuntu 22.04 和 4060 不兼容""CUDA 11.3 和 40 系显卡不兼容"的说法，这里说点实际的。问题的根源有两层：

第一层是 40 系显卡（Ada 架构）需要足够新的驱动才能点亮和跑 CUDA。如果你用 Ubuntu 22.04 默认源里最早的驱动版本，确实可能点不亮 4060，这就是"不兼容"传言的来源。解决办法很简单：装 535 或更新版本的驱动。

第二层是 CUDA Toolkit 本身。CUDA 11.3 发布时间远早于 Ada 架构，它不认识新的 GPU 架构代号，所以用 nvcc 编译代码时如果没有指定-arch=compute_89这类 Ada 参数，生成的老架构 PTX 在 4060 上虽然能通过 JIT 跑，但性能可能打折扣。如果坚持要在 4060 上用 CUDA 11.3，编译时注意加上合适的架构参数，或者接受部分依赖老特性的算子性能不佳的现实。

实际情况是，很多人在 4060 上跑 PyTorch + CUDA 11.3 是正常的，因为 PyTorch 的预编译包已经内置了多架构支持。如果项目不需要本地编译 CUDA 扩展，驱动装好直接就能用。所以我建议：先装上试，跑不通再排查架构问题，不要被传言吓得不敢动手。

6.5 降级过程中的容错心态与恢复手段

折腾环境最怕的是把系统搞到进不去桌面或循环登录。我做的操作里有几个容错点值得你提前准备好：

第一，CUDA 驱动和 Toolkit 分开装是避免灾难的最有效手段。我的流程里驱动与 Toolkit 完全独立，就算 Toolkit 装失败了，也不影响系统图形界面。

第二，如果循环登录，大概率是驱动问题。处理方式是在登录界面按 Ctrl+Alt+F2 进入 tty，卸载驱动重装：

sudo apt purge nvidia-* sudo reboot

第三，多版本共存时如果某个版本的库路径污染了系统，最快的回滚方式是删掉/usr/local/cuda这个软链接并恢复环境变量，系统在短时间内回到没有 CUDA 的状态，再慢慢修。

7. 最后几个实操收尾建议

CUDA 11.3 在 Ubuntu 22.04 上降级安装这件事，核心链条其实很短：装兼容的驱动，用 runfile 装 Toolkit，配好环境变量，管理好软链接。但整个过程中最容易被忽略的细节往往是库路径缓存、GCC 版本、cuDNN 配套这些"软件配置层面"的东西，而不是安装命令本身。

我个人在实际操作中养成了几个习惯，写出来给你做个参考：

第一个是每次装完一定跑一遍nvcc -V、nvidia-smi、deviceQuery、ldconfig -p | grep cudart四连，确保编译器、驱动、运行时库三个层面都对齐，缺一个都不算完成。

第二个是切换 CUDA 版本后，绝不只在新终端里验证，旧的终端窗口必须关掉重开。环境变量在终端启动时就固化了，旧窗口里 echo 出来的还是老路径，很多人在这上面浪费过时间。

第三个是把常用命令固化到笔记里。装 CUDA 这种一年未必操作几次的事情，半年后再做很容易忘细节，留一份带注释的命令清单，按顺序执行就好。

如果你后续要在同一台机器上跑多个 CUDA 版本的项目，建议再花点时间整理一下 CMake 工程里的find_package(CUDA)或find_package(CUDAToolkit)配置，确保这些工程使用CUDA_HOME环境变量而不是硬编码路径。这样整个 Ubuntu 22.04 的多 CUDA 环境才算真正可控。