qt creator启动后“编译器列表为空”并非软件故障，而是未检测到已安装的编译器可执行文件；根本原因是qt creator仅检测本地工具链，不自动安装编译器，需手动勾选online installer中的mingw或msvc组件，并确保vcvarsall.bat正确注入环境变量以完成msvc识别。
Qt Creator 启动后“编译器列表为空”
这不是 Qt Creator 坏了，而是它根本没扫描到任何可用的编译器可执行文件。常见于全新安装 Qt 或重装系统后——Qt Creator 不会自动下载编译器，只负责检测已安装的工具链。
- 先确认你是否真的装了编译器：Windows 上打开命令行，直接运行
cl.exe（MSVC）或g++.exe（MinGW），如果报“不是内部或外部命令”，说明编译器压根没装或没加进系统 PATH - Qt Online Installer 默认不勾选编译器组件，必须手动展开 “Developer and Designer Tools” → 勾选对应 MinGW 或 MSVC 工具链（如
MinGW 11.2.0 64-bit或MSVC 2022 64-bit） - 即使装了，Qt Creator 也可能因启动方式绕过环境变量：从开始菜单启动的 Qt Creator 不继承用户 shell 的 PATH；验证方法是 Help → About Plugins → Environment，看实际生效的
PATH是否包含gcc.exe或cl.exe所在目录
手动添加 MSVC 编译器但提示“unknown compiler”
Qt Creator 能看到 cl.exe 路径，却无法识别其 ABI 或版本，本质是缺少环境初始化脚本支持。MSVC 不是独立二进制，依赖 vcvarsall.bat 注入关键变量（INCLUDE、LIB、PATH）。
Qt Creator 18.0.2
下载
Qt Creator 18.0.2 Windows x86_64 历史版本安装包，适合需要旧版本 IDE、旧项目兼容、Qt/C++ 项目维护、构建套件配置和调试环境回退的用户使用。
- 不要只填
cl.exe路径，而要使用 Qt Creator 的“Microsoft Visual C++”类型添加，并指定平台（如 x64）、SDK 版本（如 10.0.22621.0）、VC 版本（如 14.41）——这些参数最终用于调用vcvarsall.bat - 典型路径示例：
C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\Build\vcvarsall.bat，注意不是cl.exe自身路径 - 若下拉菜单里没有对应 MSVC 版本选项，说明 Qt Creator 没读到注册表中 Visual Studio 的安装信息，此时需确保已安装 “C++ build tools” 工作负载，且未被 Windows 更新静默卸载
Kit 显示黄色警告：“Compiler not found”
Kit 已存在，但编译器字段为空或标红，说明 Kit 和编译器之间的绑定断裂，而非编译器本身缺失。
- 进入 Tools → Options → Kits → Compilers，确认目标编译器已列出且状态正常（非灰色）；若为灰色，说明其路径失效（如 VS 升级后
cl.exe移动了位置） - 回到 Kits 标签页，选中该 Kit，在 “C Compiler” 和 “C++ Compiler” 下拉框中，手动选择你刚确认有效的编译器条目——不能留空，也不能选“None”
- 务必检查 Qt 版本是否匹配：装的是
msvc2022_64，Kit 就不能配mingw_64；ABI 不一致（如 msvc2019 vs msvc2022）会导致构建时链接失败，但 Kit 表面仍可能显示“可用”
命令行运行 qmake 报错 “Cannot run compiler 'cl'”
这个错误和 Qt Creator 界面无关，是 qmake 在 shell 中执行时找不到编译器环境，说明 vcvarsall.bat 没被调用。
- 不要直接双击运行命令行，而要用 Visual Studio 提供的专用终端：“Developer Command Prompt for VS 2022”，它已预执行
vcvarsall.bat - 若需脚本化，写批处理时必须用
call：例如call "C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\Build\vcvarsall.bat" x64，否则环境变量只在子 shell 生效 - qmake 本身不管理编译器环境，它只是生成 Makefile；真正调用
cl.exe的是后续的nmake或jom，所以错误发生在构建阶段而非 qmake 阶段
