1. 为什么这两个环境变量如此重要如果你在Linux或Windows上折腾过CUDA开发尤其是用CMake来构建项目那么“CUDA_PATH”和“CUDA_TOOLKIT_ROOT_DIR”这两个名字你一定不陌生。它们就像两个经常被提起但又总让人有点迷糊的“老熟人”。很多人可能只是照着教程在.bashrc或者系统属性里设置一下项目能编译通过就万事大吉。但你真的理解它们各自扮演的角色以及为什么CMake、Visual Studio或者某些构建脚本会如此依赖它们吗简单来说CUDA_PATH在Windows上通常是CUDA_PATH或CUDA_PATH_VX_Y其中X.Y是版本号是NVIDIA官方CUDA安装程序为你设置的环境变量。它指向的是CUDA Toolkit在你系统中的安装根目录比如C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.8或/usr/local/cuda-11.8。这个变量是“官方认证”的路径标识很多NVIDIA自家的工具、示例和安装程序都会认它。而CUDA_TOOLKIT_ROOT_DIR则更像是一个“社区约定”或“构建系统偏好”的变量。它没有官方安装程序会自动设置但却是CMake在寻找CUDA时最“喜欢”看的变量之一。当你运行find_package(CUDA)或启用CUDA语言支持时CMake会优先检查这个变量如果找到了就直接用它作为CUDA Toolkit的根目录省去了在系统默认路径下大海捞针的麻烦。那么为什么我们需要关心这个因为混乱或缺失的环境变量是CUDA开发中最常见的“拦路虎”之一。错误信息可能五花八门比如CMake报错“Could NOT find CUDA”编译器抱怨“找不到cuda_runtime.h”或者链接器甩出一堆“undefined reference tocudaMalloc”。这些问题十有八九都能追溯到这两个环境变量没有正确设置或者系统中有多个CUDA版本导致了冲突。理解并正确设置它们是搭建一个稳定、可复现的CUDA开发环境的第一步。2. 深入拆解CUDA_PATH vs. CUDA_TOOLKIT_ROOT_DIR虽然它们最终都指向同一个地方——CUDA Toolkit的安装目录但设计初衷和使用场景有微妙差别。搞清楚这些差别能帮你更好地应对各种构建工具和复杂环境。2.1 CUDA_PATHNVIDIA的“官方身份证”CUDA_PATH是NVIDIA安装程序无论是.run文件还是Windows的exe在安装完成后自动为你设置的系统或用户环境变量。它的存在是为了给操作系统和其他应用程序一个明确的、标准的信号“嘿CUDA装在这里了”典型路径:Windows:C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\vX.YLinux/macOS:/usr/local/cuda通常是一个指向具体版本如cuda-11.8的符号链接或直接是/usr/local/cuda-X.Y谁在用:Visual Studio: 在Windows上当你创建CUDA项目时VS的构建系统会读取CUDA_PATH来定位nvcc编译器、头文件和库。NVIDIA Nsight、CUDA Samples: 这些NVIDIA自家的工具和示例代码默认依赖此变量来找到CUDA环境。一些第三方安装脚本: 有些软件在检测CUDA时也会首先查找这个变量。一个重要细节——版本化变量: 在Windows上如果你安装了多个CUDA版本安装程序除了设置通用的CUDA_PATH指向最新版本外还会为每个版本设置一个版本化的变量如CUDA_PATH_V11_8。这为多版本管理提供了可能。但在Linux下通常只有一个CUDA_PATH或/usr/local/cuda链接管理多版本需要手动切换这个链接或使用环境模块如module。注意在Linux系统中CUDA_PATH这个变量名并非绝对强制。有时你可能看到的是CUDA_HOME或者干脆没有。更常见的做法是直接使用/usr/local/cuda这个符号链接。但为了与Windows保持一致以及应对某些严格依赖CUDA_PATH的脚本主动设置它是一个好习惯。2.2 CUDA_TOOLKIT_ROOT_DIRCMake的“优先通行证”这个变量并非由官方安装程序设置它的“江湖地位”主要来自于CMake社区和FindCUDA.cmake模块在较新CMake版本中是内置的CUDA语言支持。你可以把它理解为给CMake的一个明确指示牌“别瞎找了CUDA就在这儿。”核心作用: 当CMake执行find_package(CUDA)或为项目启用CUDA语言时它的查找逻辑有一个优先级首先检查用户是否通过-DCMAKE_PREFIX_PATH、-DCUDA_TOOLKIT_ROOT_DIR等CMake变量指定了路径。其次检查CUDA_TOOLKIT_ROOT_DIR这个环境变量。最后才去搜索系统默认路径如/usr/local/cuda,C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA以及CUDA_PATH环境变量。为什么需要它在以下场景中CUDA_TOOLKIT_ROOT_DIR显得尤为重要系统中有多个CUDA版本你的系统可能同时安装了CUDA 11.8用于生产CUDA 12.1用于测试新特性。通过为不同的终端会话或构建脚本设置不同的CUDA_TOOLKIT_ROOT_DIR你可以精确控制CMake使用哪个版本而无需修改系统级的/usr/local/cuda链接或CUDA_PATH。非标准安装路径也许你把CUDA安装在了/opt/cuda/或者D:\Libs\CUDA\。系统查找不到但通过设置这个变量CMake就能轻松找到。持续集成/自动化构建CI/CD在Jenkins、GitLab CI等环境中你通常需要明确指定构建依赖的路径。将CUDA_TOOLKIT_ROOT_DIR作为构建脚本的一部分进行设置可以确保构建环境的一致性和可重复性避免依赖宿主机不确定的全局配置。2.3 二者的关系与协作在理想情况下CUDA_PATH和CUDA_TOOLKIT_ROOT_DIR应该指向同一个目录。这样无论是NVIDIA工具还是CMake都能和谐共处。但现实中冲突往往发生在多版本共存时。例如系统CUDA_PATH指向了v12.1但你的一个老项目必须用v11.8编译。如果你只在命令行用nvcc可能通过绝对路径指定就行。但如果你用CMake它可能还是会顺着CUDA_PATH找到12.1导致头文件版本不匹配。这时在调用CMake之前在终端里设置export CUDA_TOOLKIT_ROOT_DIR/usr/local/cuda-11.8就能“覆盖”CMake的默认查找行为强制它使用11.8。一个简单的类比CUDA_PATH像是你家的官方户籍地址邮局、政府都认这个。CUDA_TOOLKIT_ROOT_DIR则像是你给某个特定快递员CMake写的详细取件备注告诉他“我今天在公司的地址别去家里”。对于这个快递员来说你的备注优先级高于户籍地址。3. 手把手配置指南从Linux到Windows理论说完了我们来点实际的。下面我将分别展示在Linux包括WSL2和Windows系统上如何正确、清晰地设置这些环境变量。我会解释每一步的目的而不仅仅是给命令。3.1 Linux (包括WSL2) 环境配置在Linux环境下我们通常在shell的配置文件中设置环境变量比如~/.bashrcBash、~/.zshrcZsh或~/.profile。第一步确定你的CUDA安装路径首先你需要知道CUDA到底装在哪了。如果你是用apt安装的可能在/usr/lib/cuda。如果是用NVIDIA的.run文件安装的默认在/usr/local/cuda-X.YX.Y是版本号。通常/usr/local/cuda是一个指向当前活跃版本的符号链接。# 查看cuda链接指向哪里 ls -l /usr/local/cuda # 或直接查找可能的cuda目录 ls -d /usr/local/cuda-* 2/dev/null假设你的CUDA 11.8安装在/usr/local/cuda-11.8并且/usr/local/cuda链接指向它。第二步编辑Shell配置文件打开你的配置文件例如对于Bashnano ~/.bashrc或者使用vim、gedit等你熟悉的编辑器。第三步添加环境变量设置在文件末尾添加如下行。我强烈建议同时设置CUDA_PATH和CUDA_TOOLKIT_ROOT_DIR并保持它们一致除非你有特殊的多版本管理需求。# 设置CUDA安装根目录 export CUDA_PATH/usr/local/cuda-11.8 # 为了兼容性也设置CUDA_HOME一些旧脚本或项目可能认这个 export CUDA_HOME$CUDA_PATH # 设置CMake优先查找的目录 export CUDA_TOOLKIT_ROOT_DIR$CUDA_PATH # 将CUDA的二进制目录包含nvcc加入PATH export PATH$CUDA_PATH/bin:$PATH # 将CUDA的库目录加入动态链接库路径 export LD_LIBRARY_PATH$CUDA_PATH/lib64:$LD_LIBRARY_PATH关键解释export命令使变量在当前shell及其子进程中可用。我们将CUDA_PATH和CUDA_TOOLKIT_ROOT_DIR都指向具体的版本路径/usr/local/cuda-11.8而不是符号链接/usr/local/cuda。这样做更精确避免了未来切换链接时带来的意外影响。将$CUDA_PATH/bin加入PATH是为了让你能在终端任何地方直接运行nvcc、nvidia-smi等命令。将$CUDA_PATH/lib64加入LD_LIBRARY_PATH是为了让系统在运行时能找到CUDA的动态库如libcudart.so。这对于运行CUDA程序至关重要。第四步使配置生效保存文件后运行以下命令让配置立即在当前终端生效source ~/.bashrc或者直接新开一个终端窗口。第五步验证配置使用以下命令验证设置是否正确# 检查环境变量 echo $CUDA_PATH echo $CUDA_TOOLKIT_ROOT_DIR # 检查nvcc编译器版本应与你安装的版本一致 nvcc --version # 检查CUDA运行时版本 cat $CUDA_PATH/version.txtWSL2特别提示在WSL2中安装CUDA请务必遵循NVIDIA官方指南。安装完成后环境变量的设置方法与原生Linux完全一致。WSL2中的CUDA路径通常也是/usr/local/cuda-X.Y。确保你的WSL2内核支持CUDA并且已安装正确的显卡驱动。3.2 Windows 环境配置Windows提供了图形化和命令行两种设置方式。图形化方式更直观适合大多数用户。第一步找到CUDA安装目录通常位于C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\vX.Y。记下这个完整路径。第二步通过系统属性设置环境变量在“开始”菜单搜索“环境变量”选择“编辑系统环境变量”。在弹出的“系统属性”窗口中点击右下角的“环境变量(N)...”按钮。在“环境变量”窗口中分为“用户变量”和“系统变量”。如果你想对所有用户生效在“系统变量”部分操作如果仅对当前用户生效在“用户变量”部分操作。建议在“用户变量”中设置避免权限问题。新建变量点击“新建...”变量名输入CUDA_PATH变量值输入你的CUDA路径例如C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.8。再次点击“新建...”变量名输入CUDA_TOOLKIT_ROOT_DIR变量值输入相同的CUDA路径。修改Path变量在用户变量或系统变量列表中找到名为Path的变量选中并点击“编辑”。在编辑环境变量窗口中点击“新建”然后添加两项%CUDA_PATH%\bin%CUDA_PATH%\libnvvp(这个路径包含一些性能分析工具可选但推荐)使用“上移”按钮将这两项移动到列表靠前的位置优先级更高。点击所有“确定”按钮保存更改。第三步验证配置你需要新开一个命令提示符CMD或PowerShell窗口因为环境变量的更改只对新启动的进程生效。# 在CMD中验证 echo %CUDA_PATH% echo %CUDA_TOOLKIT_ROOT_DIR% where nvcc # 查看nvcc命令的位置应该在你刚添加的路径下 # 在PowerShell中验证 $env:CUDA_PATH $env:CUDA_TOOLKIT_ROOT_DIR Get-Command nvcc | Select-Object Source使用PowerShell脚本临时设置对于需要临时切换CUDA版本的场景你可以在PowerShell脚本中动态设置# 临时将CUDA 11.8加入当前会话的环境 $CudaPath C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.8 $env:CUDA_PATH $CudaPath $env:CUDA_TOOLKIT_ROOT_DIR $CudaPath $env:PATH $CudaPath\bin; $env:PATH这种方式设置的变量只在当前PowerShell会话中有效关闭窗口后即失效非常适合做多版本测试。4. 与CMake的实战集成让构建系统准确找到CUDA环境变量设好了最终是为了让构建工具能干活。CMake是现代C/CUDA项目最常用的构建系统生成器。下面我们看看如何在实际项目中运用这些变量。4.1 基础CMakeLists.txt配置一个最简单的、能启用CUDA并找到Toolkit的CMakeLists.txt可能长这样cmake_minimum_required(VERSION 3.18) # 需要3.8以支持较好的CUDA语言特性3.18更好 project(MyCudaProject LANGUAGES CXX CUDA) # 关键在project中声明CUDA语言 add_executable(my_cuda_app main.cu kernel.cu) # 链接CUDA运行时库CMake会自动处理 target_link_libraries(my_cuda_app PRIVATE CUDA::cudart)当你运行cmake -B build -S .时CMake会启动它的查找逻辑。如果CUDA_TOOLKIT_ROOT_DIR环境变量已经设置CMake会首先使用它一切顺利。如果没有设置CMake会去搜索默认路径和CUDA_PATH。4.2 显式指定CUDA路径给CMake在复杂环境中最可靠的做法是在调用CMake时通过命令行参数显式指定路径。这完全覆盖了环境变量和默认搜索。# Linux/macOS cmake -B build -S . \ -DCMAKE_PREFIX_PATH/usr/local/cuda-11.8 \ -DCUDA_TOOLKIT_ROOT_DIR/usr/local/cuda-11.8 # Windows (CMD) cmake -B build -S . -DCMAKE_PREFIX_PATHC:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.8 -DCUDA_TOOLKIT_ROOT_DIRC:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.8 # Windows (PowerShell) cmake -B build -S . -DCMAKE_PREFIX_PATHC:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.8 -DCUDA_TOOLKIT_ROOT_DIRC:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.8参数解释-DCMAKE_PREFIX_PATHpath: 这是一个通用的CMake变量用于提示find_package、find_library等命令在哪些前缀路径下搜索。添加CUDA路径到这里是个好习惯。-DCUDA_TOOLKIT_ROOT_DIRpath: 这是给CMake的FindCUDA模块或内置CUDA支持的最直接提示。4.3 处理多版本CUDA与工具链文件对于需要严格管理依赖版本的大型项目或团队推荐使用CMake的工具链文件Toolchain File。你可以创建一个如toolchain-cuda118.cmake的文件# toolchain-cuda118.cmake set(CMAKE_CUDA_COMPILER /usr/local/cuda-11.8/bin/nvcc) # 显式指定nvcc set(CMAKE_CUDA_TOOLKIT_ROOT_DIR /usr/local/cuda-11.8) # 显式指定根目录 # 也可以设置相关的包含路径和库路径但通常CMAKE_CUDA_TOOLKIT_ROOT_DIR就够了然后在配置项目时使用它cmake -B build -S . -DCMAKE_TOOLCHAIN_FILE/path/to/toolchain-cuda118.cmake这种方式将CUDA版本的选择与项目源代码和主要的CMakeLists.txt完全解耦配置信息集中在工具链文件中非常清晰也便于CI/CD系统使用。4.4 常见CMake CUDA错误排查即使设置了环境变量CMake可能仍然报错。以下是一些常见问题及解决思路“Could NOT find CUDA (missing: CUDA_TOOLKIT_ROOT_DIR)”原因CMake的FindCUDA模块没找到任何有效的CUDA安装。解决确认CUDA_TOOLKIT_ROOT_DIR或CUDA_PATH环境变量设置正确且已生效新开终端测试。尝试用-DCUDA_TOOLKIT_ROOT_DIR在命令行显式指定。检查指定路径下是否存在bin/nvcc、include/cuda_runtime.h等关键文件。“The CUDA compiler identification is unknown”原因CMake无法识别或执行nvcc编译器。解决确保nvcc所在的目录$CUDA_PATH/bin已加入系统的PATH环境变量。在Linux下运行which nvcc确认可找到。在Windows下运行where nvcc。尝试在CMake中直接设置CMAKE_CUDA_COMPILER变量指向nvcc的绝对路径。编译时找不到头文件如cuda_runtime.h原因CUDA包含路径没有正确传递给编译器。解决确保CUDA_TOOLKIT_ROOT_DIR指向的目录下有include文件夹。在CMakeLists.txt中可以使用target_include_directories(my_target PRIVATE ${CMAKE_CUDA_TOOLKIT_INCLUDE_DIRECTORIES})来添加标准CUDA头文件路径。现代CMake在启用CUDA语言后通常会自动为CUDA目标添加这些路径。链接时找不到CUDA库如libcudart.so原因CUDA库路径没有正确传递给链接器。解决确保LD_LIBRARY_PATHLinux或PATHWindows包含了CUDA的库目录。在CMake中使用target_link_libraries(my_target PRIVATE CUDA::cudart)这种现代目标式链接命令CMake会自动处理库路径和依赖。避免使用旧的、类似link_directories(${CUDA_LIBRARIES})这样的命令。5. 高级场景与疑难杂症处理掌握了基础配置后我们来看看更复杂的情况和那些容易踩坑的地方。5.1 多版本CUDA共存与切换这是CUDA开发者尤其是研究人员和需要维护多个历史项目的工程师经常面临的挑战。Linux下的优雅切换使用update-alternativesupdate-alternatives是Debian/Ubuntu系Linux发行版管理多版本命令链接的工具。你可以用它来管理/usr/local/cuda这个符号链接。# 假设已安装cuda-11.8和cuda-12.1 sudo update-alternatives --install /usr/local/cuda cuda /usr/local/cuda-11.8 100 sudo update-alternatives --install /usr/local/cuda cuda /usr/local/cuda-12.1 200 # 交互式选择要使用的版本 sudo update-alternatives --config cuda执行--config后会列出所有已注册的版本输入序号即可切换。切换后/usr/local/cuda链接会指向你选择的版本。你的CUDA_PATH和CUDA_TOOLKIT_ROOT_DIR环境变量如果指向的是/usr/local/cuda那么它们也会随之切换。但更推荐的做法是在需要特定版本的项目中通过脚本或CMake命令行参数临时指定具体路径而不是修改全局链接。使用环境模块Environment Modules 对于HPC集群或更复杂的环境module命令是管理多版本环境变量的标准工具。你可以加载或卸载不同的CUDA模块来切换整个环境。module avail cuda # 查看可用的CUDA模块 module load cuda/11.8 # 加载CUDA 11.8环境 module list # 查看当前加载的模块这通常由系统管理员配置好用户只需简单的load和unload命令即可。虚拟环境或容器化 对于追求极致环境隔离和可复现性的场景使用Conda虚拟环境通过conda install cuda-toolkit可以安装特定版本的CUDA到虚拟环境中或Docker容器是更好的选择。在容器内环境是独立的不存在主机版本冲突问题。5.2 与Anaconda/Python虚拟环境的交互在数据科学和机器学习领域我们经常在Anaconda虚拟环境中工作。这里有一个巨大的陷阱Conda环境中的CUDA可能与系统CUDA冲突。当你conda install pytorch或tensorflow时Conda可能会自动安装一个与该PyTorch/TensorFlow版本匹配的cudatoolkit包。这个包是独立于你系统安装的CUDA Toolkit的它只包含运行PyTorch/TensorFlow所需的运行时库如libcudart不包含nvcc编译器。带来的问题你在终端里which nvcc找到的是系统CUDA的nvcc例如11.8。但你的PyTorch是在Conda环境中用cudatoolkit12.1安装的。当你编译一个需要链接PyTorch的CUDA C扩展时如果用系统11.8的nvcc编译但链接了Conda环境里12.1的libcudart极有可能导致版本不兼容而编译失败或运行时崩溃。解决方案方案A推荐在Conda环境中也安装完整的nvcc编译器。你可以安装conda-forge频道提供的cuda-toolkit包它会安装一个包含nvcc的完整CUDA工具链到当前环境。conda activate my_env conda install -c conda-forge cuda-toolkit安装后该环境内的nvcc、CUDA_PATH等都会指向Conda环境内的版本与系统隔离避免了冲突。方案B如果只是运行PyTorch/TensorFlow不进行自定义CUDA内核编译那么可以忽略系统nvcc。编译扩展时确保使用PyTorch提供的编译命令如python setup.py build_ext它会处理好内部的依赖关系。关键检查在虚拟环境中始终使用import torch; print(torch.version.cuda)来确认PyTorch使用的CUDA运行时版本并与你打算用来编译的nvcc --version输出进行比对确保它们一致或兼容。5.3 在IDE中配置VSCode, CLion, Visual Studio集成开发环境通常有自己的配置体系需要正确设置才能实现代码提示、智能感知和正确构建。Visual Studio 在Windows上如果你通过官方安装程序安装了CUDAVS通常会自动检测到。创建新项目时选择“CUDA”模板即可。如果需要手动指定可以在项目属性页中配置VC目录-包含目录添加$(CUDA_PATH)\include。VC目录-库目录添加$(CUDA_PATH)\lib\x64。链接器-输入-附加依赖项添加cudart.lib等。 但更现代的做法是使用CMake项目然后在CMake中配置VS会继承这些设置。VSCode VSCode本身不负责构建它依赖任务Tasks和扩展。对于CUDA开发安装“CMake Tools”扩展。在项目根目录创建或配置CMakePresets.json在其中指定CUDA_TOOLKIT_ROOT_DIR等变量。或者在.vscode/settings.json中可以配置cmake.configureSettings来传递参数{ cmake.configureSettings: { CUDA_TOOLKIT_ROOT_DIR: C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v11.8 } }对于代码提示确保你的c_cpp_properties.json通过C/C扩展生成中的includePath包含了CUDA的头文件路径例如${env:CUDA_PATH}/include。CLion CLion原生支持CMake因此配置方式与命令行CMake高度一致。你可以在File - Settings - Build, Execution, Deployment - CMake中的“CMake options”里添加-DCUDA_TOOLKIT_ROOT_DIR...参数。或者更规范的做法是在项目的CMakeLists.txt或CMakePresets.json中定义好。5.4 排查“环境变量已设置但不起作用”的终极思路有时候明明设置了变量但CMake或程序就是找不到。可以按照以下步骤系统性排查验证环境变量在目标shell中是否真正可见在你运行CMake的同一个终端里执行echo $CUDA_TOOLKIT_ROOT_DIRLinux或echo %CUDA_TOOLKIT_ROOT_DIR%CMD或$env:CUDA_TOOLKIT_ROOT_DIRPowerShell。如果输出为空说明变量没被加载。检查你的配置文件.bashrc,.zshrc并确保你已source或重启了终端。检查CMake的查找过程在CMake配置命令中添加--trace-expand或--debug-find参数这会让CMake输出极其详细的查找过程你可以看到它究竟在哪些路径下搜索了CUDA。cmake -B build -S . --debug-find 21 | grep -i cuda检查CMake缓存CMake会将找到的变量存入CMakeCache.txt。删除build目录重新配置是最干净的方法。或者在CMakeCache.txt中搜索CUDA查看CUDA_TOOLKIT_ROOT_DIR、CMAKE_CUDA_COMPILER等变量的缓存值是否与你预期的一致。如果不一致可以手动编辑该文件不推荐新手或清除缓存重试。权限与路径问题确保你设置的路径存在并且当前用户有读取和执行权限对于bin/nvcc尤其需要执行权限。在Linux上可以用ls -la /usr/local/cuda-11.8/bin/nvcc检查。终端类型与配置文件如果你用的是Zsh~/.zshrc但只在Bash~/.bashrc中配置了变量那当然不生效。确保你的shell类型和配置文件匹配。图形化启动的IDE如VSCode、CLion可能不会继承你终端里source的环境变量。它们通常读取的是登录时的初始环境。对于这种情况要么在IDE的配置文件中设置要么通过系统的“环境变量”设置Windows或~/.profile、/etc/environmentLinux进行全局设置。设置CUDA_PATH和CUDA_TOOLKIT_ROOT_DIR本身并不复杂但理解其背后的逻辑并能在多版本、虚拟环境、复杂构建系统等场景下游刃有余地运用才是从“能用”到“精通”的关键。记住核心原则CUDA_PATH是给系统和NVIDIA工具看的“官方地址”CUDA_TOOLKIT_ROOT_DIR是给CMake等构建系统的“特别指示”。在自动化脚本和跨平台项目中显式地通过CMake变量-D传递路径总是比依赖可能不稳定的全局环境变量更加可靠。下次再遇到CUDA找不到的问题时希望这份指南能帮你快速定位到那个“迷失”的工具包。