我先把这次踩坑的背景交代清楚：手头一台刚装的Ubuntu 24.04 LTS，从源代码编译一个Qt Widgets项目，需要完整的Qt Creator图形开发环境。本以为apt install一条命令就能搞定，结果从启动到建工程到跑起来，一连串问题排着队来。这篇文章就把我实际遇到的和周边朋友高频踩的问题整理成一份可查的合集，按安装、启动、编译、输入法、日常排查五个部分展开，全部基于Ubuntu 24.04真实环境，不扯虚的。

1. 先理清楚Ubuntu 24.04下的Qt Creator现状

Ubuntu 24.04 LTS（Noble Numbat）默认软件源里带的Qt Creator版本是6.x系列，对应系统自带的Qt库也是Qt 6.6以上的版本。这条信息很关键，因为网上大量教程还在讲Ubuntu 22.04、Qt 5.15，照搬过来会踩很多坑。

先说第一个认知：apt直接安装的是Qt 6系绑定版。

sudo apt update && sudo apt install qtcreator

这条命令装出来的Qt Creator，默认会去加载系统自带的Qt 6库，而不是你自己下载的某个Qt 5.15或者Qt 6.2商业包。如果你只需要用系统Qt做开发和调试，这样装基本够用。但问题往往出在两类场景上：

• 项目是老工程，依赖Qt 5.15甚至更低版本，系统只有Qt 6，编译器切不过来。
• 需要某个特定Qt版本（比如Qt 5.12、Qt 5.15 LTS）来配合特定模块，系统源里没有。

很多人在这一步就开始迷茫，然后去Qt官网下载在线安装器，又遇到在线安装器在Ubuntu 24.04上启动失败的问题，绕了一个大圈子。这里我明确建议：先用apt方案跑通最小环境，确认系统能正常启动Qt Creator并且能编译运行一个简单的Widgets工程，再考虑装独立Qt版本。哪怕你是老手，这个顺序也能帮你区分到底是系统级问题还是Qt版本问题，排查效率高得多。

另外，Qt Creator本身是个前端IDE，它不绑定编译器也不绑定Qt库。你完全可以只装Qt Creator，然后让它调用系统自带的gcc/g++、CMake和系统Qt。这么做的好处是依赖面最小，问题也最少。不要一上来就想全装，Qt官方在线安装器里那一堆组件很容易把人搞晕，装的越多，后面冲突的概率越大。

2. 安装方式选择与高频问题实录

2.1 apt安装看似省事，但你要留意这几个细节

apt方式安装Qt Creator时，系统会同时拉进来一堆依赖，包括Qt 6运行库、clang相关组件、LLVM、CMake等等。安装本身一般不会报错，真正出问题的是装完之后那几个关联包的状态。

我实测遇到的一个典型情况：装完之后sudo apt upgrade一跑，openssl、libclang之类的库被升了级，Qt Creator的代码模型插件（ClangCodeModel）偶尔会抽风，症状是代码高亮失效、自动补全消失。这是因为libclang版本和Qt Creator编译时用的版本对不上。解决办法倒不难，把相关库锁住版本：

sudo apt-mark hold libclang-cpp* sudo apt-mark hold libclang1*

这个技巧在网上很少有人提，我遇到两次之后干脆把版本锁定写进笔记里。如果你对自动补全没那么依赖，也可以省心不管，反正编译和调试不受影响。

还有一类安装问题是依赖残留：以前装过某个Qt版本，手动卸载没卸干净，apt安装qtcreator时提示依赖冲突。这种情况我的处理方式是：

sudo apt --fix-broken install sudo dpkg --configure -a

先把系统包管理状态修复干净，再装Qt Creator。急着硬上会留下更多问题，得不偿失。

2.2 Qt官方在线安装器的启动失败与破局

如果你确实需要装官方独立版Qt，会发现在Ubuntu 24.04上在线安装器经常出现启动即黑屏、闪退或者报xcb插件错误的情况。这不完全是你的系统有问题，根源在于Qt官方安装器使用的Qt版本较旧，而Ubuntu 24.04的图形环境相对较新，两者在xcb库支持上衔接得不好。

经典报错长这样：

qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found

这句提示绝大多数人看不懂。它说的不是找不到xcb插件，而是xcb插件加载后初始化失败，通常原因是缺少某些底层xcb运行库。Ubuntu 24.04上最容易缺的是这一组：

sudo apt install libxcb-icccm4 libxcb-image0 libxcb-keysyms1 libxcb-randr0 libxcb-render-util0 libxcb-shape0 libxcb-xinerama0 libxcb-cursor0 libxcb-xkb1 libxkbcommon-x11-0

这里面libxcb-cursor0是出镜率最高的一个。Qt 5.15及以上版本在较新系统上启动时如果缺这个库，就会给你看上面那个“Could not load the Qt platform plugin xcb”的提示。Ubuntu 22.04时代很多人没遇到，是因为系统默认引入了；24.04上的某些最小化安装环境还真就没有。

装完这些库之后，建议重启一次Qt Creator，或者直接退出重新打开。如果是从终端启动的，也可以观察一下终端输出里有没有其他缺失的.so符号。

如果你嫌一个个试太烦，还有一个更痛快的办法：直接把常见运行库一次性装全：

sudo apt install libxcb-* libxkbcommon-* libxkbcommon-x11-* libgl1-mesa-dev libegl1-mesa-dev

这一套下来的体积也不大，但能避免太多“缺一个库启动不了”的尴尬。实测在干净安装的Ubuntu 24.04系统上，装完这些之后无论是Qt Creator 6还是各种基于Qt的软件都能正常启动。

2.3 旧版本Qt Creator的获取途径与注意点

有些朋友问怎么装Qt Creator旧版本。如果你打开Qt官网的archive页面，会发现历史版本都放在一个不起眼的目录里。网址形式大致是https://download.qt.io/official_releases/qtcreator/，里面有老版本和新版本子目录。下载对应平台的.run或.sh文件后，先给执行权限再运行：

chmod +x qt-creator-opensource-linux-x86_64-*.run ./qt-creator-opensource-linux-x86_64-*.run

旧版Qt Creator有个坑：它们依赖的系统库版本比较老，在24.04上一样可能触发xcb问题。所以即使下载了旧版本，上面提到的那组依赖库同样得装。另外还要小心你机器上是否装了多个版本的Qt Creator，菜单项容易混。建议只保留一个，或者每次启动用全路径调用。

我个人的经验是：不需要刻意追求旧版本。Qt Creator 9/10/11这些新版本在功能上完全是旧版超集，老工程出问题更多是Qt库版本与编译器的事，跟IDE本身版本关系不大。真要处理老工程，建议在新版Qt Creator里添加老版本Qt的Kit，而不是把IDE降级。

3. 启动失败与显示环境问题排查

3.1 平台插件“xcb”这类报错，其实是套娃问题

Qt程序启动时依赖“平台插件”，这个插件负责和系统窗口系统对话。Linux下最常见的就是xcb。Qt Creator在启动时会先去寻找libqcocoa等平台插件文件，找到之后加载、初始化、连接X Server。

如果你看到“Could not load the Qt platform plugin xcb”这段话，我建议按以下顺序排查，不要一上来就重装Qt。

第一，确认DISPLAY环境变量有值：

echo $DISPLAY

X11会话下一般输出:0或:1。如果空着，说明你的shell没继承图形环境变量，从桌面菜单启动一般不存在这问题，但从某些终端模拟器启动时可能会碰到。

第二，确认xcb库完整。运行ldd检查Qt平台插件依赖：

ldd /path/to/Qt/plugins/platforms/libqxcb.so | grep "not found"

只要有输出，缺哪个就装哪个。这个方法能精确定位，比盲目装一堆库更高效。

第三，检查libgl相关。Qt Creator还需要OpenGL支持，很多报错其实卡在GL初始化失败上，只是最终显示的还是xcb。安装mesa库：

sudo apt install libgl1-mesa-dev libegl1-mesa-dev mesa-common-dev

这三个库装完，90%的GL初始化问题就消失了。

第四种情况比较隐蔽：Qt Creator启动时报“cannot mix incompatible Qt libraries”，说明系统里存在多个Qt安装，环境变量打架了。最常见的坑是以前编译过某个软件时把LD_LIBRARY_PATH写进了~/.bashrc，指向了一个古老的Qt目录。检查一下：

echo $LD_LIBRARY_PATH

如果输出里有/usr/lib/x86_64-linux-gnu/qt5或者某个自定义的Qt路径，试试先清空再启动：

unset LD_LIBRARY_PATH qtcreator

我遇到过两次，都是因为手贱在.bashrc里加了一行指向Qt 5.12的LD_LIBRARY_PATH，结果Qt Creator无论如何都起不来。

3.2 Wayland与X11的切换问题

Ubuntu 24.04默认登录界面往往选择Wayland会话。Qt Creator 6本身对Wayland支持还行，但老版本程序在Wayland下容易出现缩放模糊、窗口错位、拖拽失效等问题。

如果你在Wayland环境下遇到诡异图形问题，建议切到Xorg会话试试。做法很简单：登录界面右下角齿轮按钮，选择“Ubuntu on Xorg”，再登录。

有些朋友不知道自己的会话类型，执行这个命令一目了然：

echo $XDG_SESSION_TYPE

另外，如果你从X11远程环境（比如VNC、X2Go）访问Ubuntu桌面，Qt Creator启动时有时会警告“Missing X server or $DISPLAY”。这种情况通常是VNC服务没启动图形环境，需要在VNC配置里启用桌面会话，或者用xhost +解决访问控制问题。后一种方式有安全风险，只建议在受信任的内网环境里临时使用。

我的实际建议：Ubuntu 24.04桌面用户，如果只是日常开发Qt，就继续用Wayland，遇到具体问题再针对性解决。不要为了追求“稳定”盲目切到Xorg，24.04上Xorg对高分屏和多显示器的支持已经明显落后于Wayland。

3.3 启动后白屏、闪退与GPU驱动的关系

有一类启动问题非常容易和依赖库问题混淆——Qt Creator启动后白屏几秒，然后直接闪退。打开终端看错误信息，出现最常见的其实是：

Failed to create OpenGL context

这表示程序不是缺库，而是这个库在运行时初始化失败。原因很可能是GPU驱动没装好，尤其当系统是双显卡或者刚装的新机器还在用nouveau驱动。

确认GPU驱动状态：

lsmod | grep -i nvidia lspci -k | grep -A 2 -E "VGA|3D"

如果是NVIDIA显卡又没装官方驱动，建议去“软件和更新”的“附加驱动”标签页里选择安装官方驱动，然后重启。驱动装好后，Qt Creator的渲染问题基本消失。

对于核显（Intel）和AMD显卡的环境，一般问题不大，但可能需要在启动Qt Creator时指定软件渲染模式：

LIBGL_ALWAYS_SOFTWARE=1 qtcreator

注意这只是一个临时验证手段，如果软件渲染下一切正常、硬件渲染下出问题，那问题十有八九出在驱动上。日常开发如果用软件渲染，大项目的代码高亮和编辑器滚动会有明显卡顿，不建议长期这么干。

3.4 启动慢、卡死与加载界面分析

还有一个常被忽视的问题：Qt Creator启动非常慢，或者启动时一直停在加载界面。这个现象在Ubuntu 24.04上有几个常见原因。

第一，ClangCodeModel插件在首次启动时要建立代码索引，尤其你的家目录下缓存了很多旧工程，索引量大，启动就慢。解决方案是定期清理缓存：

rm -rf ~/.cache/qtcreator rm -rf ~/.config/QtProject

注意：清空~/.config/QtProject会丢掉所有IDE设置和套件配置。建议先备份，再清理。

第二，插件加载过多。Qt Creator默认开了一大堆插件，很多你可能一辈子用不到，比如Perforce、ClearCase、Subversion这些版本控制插件。在“帮助-关于插件”里把不用的禁用，启动速度能快不少。

第三，磁盘IO问题。如果你把Qt Creator装在机械硬盘上，启动时会初始化大量插件库，确实比SSD慢很多。这个没法彻底优化，尽量用SSD吧。

4. 编译工具链与Kit配置的硬核细节

4.1 编译器、CMake版本和构建工具的准备

Qt Creator本身只是个壳，真正干活的编译器、CMake、调试器都得自己配齐。很多新手在“套件（Kit）”页面看到一堆红叉，就是这些工具没装。

Ubuntu 24.04下最低限度要装：

sudo apt install build-essential cmake ninja-build gdb

• build-essential提供gcc/g++和make。
• cmake是大多数Qt工程（尤其CMake工程）必需的构建工具。
• ninja-build比make并行构建更快，Qt Creator对它支持得很好。
• gdb是调试器。

Ubuntu 24.04自带的CMake版本应该是3.25以上，对于绝大多数Qt 6工程完全够用。如果项目要求更高版本的CMake，不建议手动编译CMake，建议用Kitware官方提供的apt源，或者直接用pip方式装一个备用版本：

pip install cmake --user

这样装出来的cmake会在~/.local/bin/cmake，和系统cmake共存，互不干扰。在Qt Creator里设置Kit时手动指定这个路径就行。

4.2 手动创建Kit的完整流程

点左侧“项目”栏目，再进入“套件（Kits）”页面。Qt Creator会自动识别不少工具链，但有时识别不全。手动创建Kit的正确姿势如下。

1. 先在“编译器”标签页点“添加”，选择GCC或Clang。Ubuntu 24.04上默认的gcc版本是13，g++也是13。如果同时装了clang，建议优先用clang，它在编译诊断信息上比GCC更友好，Qt Creator配合也更顺畅。

2. 在“调试器”标签页添加/usr/bin/gdb。注意有些精简系统没装，按上面命令装上即可。

3. 在“CMake”标签页添加/usr/bin/cmake。如果你想手动指定，用which cmake找到路径。

4. 最关键的一步：新建Kit时，在“Qt版本”一栏选择对应的Qt安装。如果你是apt源方式，通常会有一个Qt 6.x (系统)选项。如果这个下拉框是空的，说明你没装Qt开发库：

sudo apt install qt6-base-dev qt6-tools-dev qt6-tools-dev-tools

装了之后，CMake工程就能找到Qt6的cmake模块。很多人只装了qtbase5-dev或者什么都没装，结果Kit里Qt版本一栏永远空着。

5. 保存套件后，在“构建套件”里勾选新加的Kit，项目就能正常构建了。

这里有个常见误区：很多人装了官方Qt，但Qt Creator里新建套件时还是报“没有合适的Qt版本”。原因是没有在“选项—Kits—Qt版本”里手动添加Qt路径。打开Qt安装目录，找到gcc_64/bin/qmake路径，添加进去。新版Qt 6安装后，qmake位于/opt/Qt/6.x.x/gcc_64/bin/qmake，而CMake工具链文件在/opt/Qt/6.x.x/gcc_64/lib/cmake，Qt Creator会自动识别。

4.3 系统Qt 6与手动安装Qt 5的共处问题

很多老工程需要Qt 5.15，但系统是Qt 6的环境。两者能否共存？可以，但有几个坑要躲。

第一，不要用apt同时安装qt5和qt6的开发包，版本冲突会让人头大。建议系统用Qt 6，老工程需要的Qt 5用官方安装器装到/opt/Qt/5.15.x这种独立目录。Qt Creator的“Qt版本”页面可以同时注册Qt 5和Qt 6，互不打架。

第二，构建老CMake工程时，注意指定Qt版本。Qt 6的CMake引入了Qt6组件名，Qt 5则是Qt5。如果你的CMakeLists是老的写法find_package(Qt5 COMPONENTS Widgets)，那就只能找Qt 5。当检测失败时，很可能是CMAKE_PREFIX_PATH没指到Qt 5安装目录。在项目构建设置里加上：

CMAKE_PREFIX_PATH=/opt/Qt/5.15.x/gcc_64

这个方法比改环境变量更可靠，因为环境变量偶尔会被系统wide的配置覆盖。

第三，运行老程序时如果需要Qt 5运行库支持，可以把Qt 5的lib目录加入LD_LIBRARY_PATH，但我不建议全局设置，影响面太大。更好的做法是在Qt Creator的“运行”环境设置里给这个特定项目单独加：

LD_LIBRARY_PATH=/opt/Qt/5.15.x/gcc_64/lib:$LD_LIBRARY_PATH

这样其他项目不受影响。

4.4 调试器配置和代码模型不工作的解法

调试器方面，Ubuntu 24.04默认gdb版本12.x，对Qt的支持还算过得去。但有些工程会报类似“No symbol table”或者“Unable to find debugger”的错误，多半是因为编译时没开调试符号。在Qt Creator的构建步骤里，把CMAKE_BUILD_TYPE设为Debug，或者直接改构建参数：

-DCMAKE_BUILD_TYPE=Debug

这样gdb才能看到完整的符号表。

如果你遇到代码模型（ClangCodeModel）显示红色波浪线、自动补全消失，先别急着重装。优先级最高的排查动作是：

1. 确认系统里有libclang。Qt Creator的代码模型依赖它，版本往往要求比较明确。Ubuntu 24.04的libclang默认是18，Qt Creator 11以上版本带的是libclang 17或18，这个组合一般没问题。
2. 如果还是不行，在“工具—选项—C++—代码模型”里点“管理”按钮，手动选择libclang的实际路径：

dpkg -L libclang-common-18-dev | grep libclang.so

通常路径是/usr/lib/llvm-18/lib/libclang.so。

3. 最后一个兜底方案：把~/.config/QtProject/qtcreator下的qtcreator.ini改名备份，让IDE恢复出厂设置。很多代码模型异常都是配置文件和版本不匹配导致的。

5. 中文输入法、字体与桌面体验

5.1 fcitx5在Qt Creator里无法输入中文的解决

Ubuntu中文用户最头疼的问题之一是：系统装了中文输入法，浏览器里能打字，但Qt Creator里输不了中文。这个问题不是Qt Creator故意不兼容，而是输入法框架和Qt程序的通信没建立起来。

Ubuntu 24.04默认的输入法框架是IBus，但很多国内用户习惯用fcitx5。如果你只用IBus，在Qt Creator里一般没问题。但如果你装了fcitx5，就要为Qt程序设置三个关键环境变量：

export QT_IM_MODULE=fcitx export GTK_IM_MODULE=fcitx export XMODIFIERS=@im=fcitx

这三个变量告诉Qt程序“请通过fcitx协议连接输入法”。缺了任何一个，都可能出现输入法面板能出来但候选词不上屏的情况。

注意，这三行写进~/.bashrc只对从终端启动的Qt Creator有效。从桌面图标启动时不会加载.bashrc，需要在/etc/environment里追加，或者做成Desktop文件的环境变量配置。

比较稳的做法是修改启动器文件：

sudo nano /usr/share/applications/qtcreator.desktop

在[Desktop Entry]段落的Exec=行改成：

Exec=env QT_IM_MODULE=fcitx GTK_IM_MODULE=fcitx XMODIFIERS=@im=fcitx qtcreator

改完后从应用菜单启动就有效了。

另一件容易忽略的事：fcitx5前端的Qt库版本要和你的Qt版本对得上。如果你的Qt Creator是系统Qt 6，就要装：

sudo apt install fcitx5-frontend-qt6

如果还装了官方独立版Qt，那还需要fcitx5-frontend-qt5来给Qt 5老工程用。很多人只装了frontend-qt5，在Qt 6程序里死活调不出输入法，就是版本没对上。

如果你用IBus，则对应的环境变量是：

export GTK_IM_MODULE=ibus export QT_IM_MODULE=ibus export XMODIFIERS=@im=ibus

5.2 字体模糊、编辑器字间距异常与高分屏缩放

Ubuntu 24.04上Qt Creator默认字体在某些环境下渲染偏淡，特别是在非整数倍缩放下（比如150%缩放）。解决方法是调整Qt Creator的字体设置，但更关键的是理解缩放机制。

Qt 6程序在高分屏下的缩放靠的是环境变量QT_SCALE_FACTOR或者桌面环境的缩放设置。如果你在设置里把显示缩放调成200%，Qt Creator一般能自动适应。如果显示模糊，可以尝试强制给Qt设置整数倍缩放：

export QT_ENABLE_HIGHDPI_SCALING=1 export QT_AUTO_SCREEN_SCALE_FACTOR=0 export QT_SCALE_FACTOR=2

注意QT_AUTO_SCREEN_SCALE_FACTOR=0是关闭自动感知，而QT_SCALE_FACTOR=2是手动指定2倍。两者配合用。但我建议不是特别严重时别这么干，因为手动指定会让字体在某些DPI下偏大，反而影响体验。

字体方面，Qt Creator默认用的等宽字体在Linux上可能是Monospace，这个字体在Ubuntu 24.04上映射到了Ubuntu Monospace，本身还行。但如果你想换成更清晰的等宽字体，可以考虑JetBrains Mono或者Cascadia Code，装好之后在“工具—选项—字体与颜色”里切换。

另外有个不太起眼的坑：系统切成中文后，Qt Creator的菜单里部分文字显示为方框。这多半是缺少中文字体。安装：

sudo apt install fonts-noto-cjk fonts-noto-color-emoji

装完之后注销重新登录，方框问题就能解决。

5.3 远程开发时Qt Creator连不上显示服务器的处理

有朋友喜欢在服务器上跑一个Ubuntu 24.04系统，然后用本地电脑通过SSH访问开发。这种情况下Qt Creator的图形界面要么在服务器上开着，要么通过X11转发。通过SSH转发Qt应用的体验在局域网还行，但跨网络延迟会明显，尤其是代码补全和光标移动的反馈。

我的建议是：不要用X11转发跑Qt Creator，体验太差了。更好的方案是：

1. 本地用Qt Creator，远程只是编译和运行，通过“设备—SSH设备”配置远程工具链，这样编辑在本机，编译和调试在服务器，流畅度好得多。
2. 用VNC或者NoMachine等远程桌面工具连到服务器桌面。
3. 用VsCode Remote SSH，但那不是本文范围。

如果你非要X11转发，注意给SSH加压缩和参数：

ssh -X -C -c aes128-gcm@openssh.com 用户名@服务器地址

至少局域网环境下不至于卡到完全没法用。

6. 高频故障速查表与避坑经验

6.1 一句话定位问题：故障现象与对应解法

我把自己踩过和帮别人排查过的问题列了一张速查表，你可以直接按图索骥。

这张表覆盖了我遇到过的绝大多数问题。如果对照表还没解决，下一步的动作很关键：别急着卸载重装，先打开终端手动启动Qt Creator，把报错信息原封不动记下来。很多问题看一眼终端最后几行输出就能定位，比网上漫无目的地搜关键词高效得多。

6.2 我的几点独家经验与建议

最后聊几点很难在官方文档和网上教程里看到的心得。

第一，关于Ubuntu 24.04这个LTS版本，Qt Creator相关的坑比22.04少，但依赖库要求更严格。如果你想长期做Qt开发，优先考虑把官方在线安装器装在/opt目录，而不是默认的~/。一方面其他账户也能访问，另一方面有些编译脚本会在路径里有空格或者中文名时翻车。Qt安装目录本身不要有中文和空格，这条要写进团队规范。

第二，建议安装器下载的文件校验一下SHA值再执行。Linux社区很多下载源的校验和都能查到，不要嫌麻烦，一次下载解压重复错误会浪费时间。

第三，Ubuntu 24.04系统的HWE内核升级比较频繁，我有一次在升级内核之后Qt Creator启动直接黑屏，查了半天是老的内核模块和新驱动不匹配。处理方式是确认当前用的内核，用uname -r查看，然后用“高级选项”启动旧内核验证。如果验证是内核问题，在“软件更新器—设置—其他软件”里把HWE内核源调整一下，或者干脆等待下一次更新。

第四，日常开发建议坚持用LTS版本的Qt库。官方对非LTS版本只维护到下一个版本发布后六个月左右，很多线上问题修了也没人给你发更新包。与其在版本更新上折腾，不如锁定一个LTS版本，把精力花在项目本身上。

第五，遇到任何图形相关疑难杂症，可以试试给Qt Creator强制用软件渲染启动一次，如果正常，基本锁定是GPU驱动或硬件加速的锅；如果依旧崩，那就是依赖库或者Qt版本本身的问题。这个二分法定位问题在Linux图形栈里非常高效。

第六，定期备份Qt Creator配置。把~/.config/QtProject/和~/.local/share/QtProject/整个打包，放在一个安全目录。很多折腾完配置后反而更糟的情况，一个备份就能让你恢复原状。

6.3 后续还可以怎么扩展

如果你在这套环境上稳定开发了一段时间，有几个方向值得继续深入。

一是配置Qt Creator的“外部工具”集成，把代码格式化工具clang-format、静态分析工具cppcheck接进来。Ubuntu 24.04上安装很干净：

sudo apt install clang-format cppcheck

在Qt Creator的“工具—外部—配置”里添加工具后，写代码时一键格式化、一键静态分析，效率提升非常明显。

二是研究一下Qt Creator的构建目录策略。很多人默认用Shadow Build，其实它在Ubuntu 24.04上的表现非常稳。至于“进程内构建”还是“外部构建”的选择，如果你用CMake工程，建议保持默认的外部构建，这样清理起来很容易，不污染源码目录。

三是针对你自己的工程类型，考虑是否要安装额外的福尔插件。比如做嵌入式开发的人，可能需要交叉编译工具链的支持；做QML开发的，Qt Creator 6自带的QML调试器已经很完善。这些都可以在“关于插件”里看到，按需启用。

我个人在实际操作中的体会是：Ubuntu 24.04上跑Qt Creator，只要你把依赖库装齐、Kit配置清楚、输入法环境变量设对，这个组合其实比大多数发行版都要省心。问题版本的文章多，是因为问题本身集中度高，并不代表这个环境难用。真正麻烦的从来不是Qt Creator，而是Linux图形栈底层库之间的隐式依赖关系。多踩几次坑、记好笔记，后面就是一帆风顺。