好端端我最早接触 Linux 开发时，干的最多的事就是打开终端敲命令，当时总觉得“开发工具链”这个词特别吓人，好像是一堆高不可攀的东西。后来在嵌入式项目里反复折腾 apt、gcc、gdb 之后才明白，所谓工具链，其实就是一条从“搞到软件”到“把代码跑起来、再把问题揪出来”的流水线。今天这篇文章，我就把自己从 apt 到 gdb 的完整使用经验整理出来，重点放在那些文档里不太会写、但实际开发中一定会遇到的坑上。不管你是刚准备从 Windows 转入 Linux 的初学者，还是已经在 Linux 上写了一段时间代码、想系统梳理一遍工具链的开发者，这篇内容都应该能帮上忙。
1. 先想清楚：一套完整的 Linux 开发工具链到底由什么组成
1.1 为什么很多人学了命令却上不了手
我见过不少朋友，Linux 常用命令背得滚瓜烂熟，ls、cd、cp、mv 张口就来，可真给他一台干净的 Ubuntu 机器，让他把一个 C 项目编译、运行、调试起来，他反而会卡住。原因很简单：命令是零散的，而开发是一个流程。
你仔细想想，在 Linux 上做开发，本质上就干五件事：把需要的软件装进来、用编辑器写代码、把源码变成可执行文件、运行出问题后定位原因、最后把产物部署到目标环境。对应到这五件事，就是今天标题里那条链路：apt（软件获取） → vim/VS Code（编辑） → gcc/make/CMake（编译构建） → gdb（调试） → systemctl/日志分析（部署运维）。缺了任何一个环节，项目都转不起来。
1.2 工具链的五大环节与协作关系
这条链路里每个环节都不是孤立的。apt 装的是“生产资料”，比如编译器、调试器、第三方库；编辑器负责生产“代码原料”；编译器把原料加工成“产品”；gdb 则是质检员，专门在出问题时把“生产事故”复现出来。我见过很多新手只盯着其中一环学，比如疯狂研究 Vim 配置，却连 -g 编译选项都没加过，结果真遇到段错误时毫无办法。
还有一个容易被忽略的点：工具链的版本匹配。尤其在嵌入式领域，交叉编译工具链、gdb 的架构、目标板的库版本，任何一环对不上，都会出现“编译能过、运行崩溃”或者“gdb 连不上目标板”这类玄学问题。后面我会专门讲这个。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. apt 不只是装包工具：源管理、依赖处理和更新慢的解法
2.1 换源实操：备份、替换、验证三步走
我对 apt 的第一印象就是“慢”。默认官方源在国外，国内网络环境下，一个 apt update 能转悠好几分钟。很多教程会让你直接改 /etc/apt/sources.list，但这一步在不同版本上有讲究。
Ubuntu 24.04 之前，软件源配置集中在 /etc/apt/sources.list 一个文件里；24.04 开始，系统改用了 Debian 830 风格的配置，源文件被拆分到 /etc/apt/sources.list.d/ubuntu.sources。我刚开始也在这上面吃过亏：照旧教程去改 sources.list，改完发现系统根本不读，因为新版根本没启用那个文件。
以清华源为例，旧版 Ubuntu 的操作是：
bash复制# 先备份，这是最重要的习惯
sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak
# 用 sed 替换为清华镜像地址
sudo sed -i 's@//.*archive.ubuntu.com@//mirrors.tuna.tsinghua.edu.cn@g' /etc/apt/sources.list
sudo sed -i 's@//security.ubuntu.com@//mirrors.tuna.tsinghua.edu.cn@g' /etc/apt/sources.list
sudo apt update
新版（24.04+）系统要改的是 ubuntu.sources，格式也不再是原来那种 deb 单行列表，而是带 URIs、Suites、Components 字段的块状结构。替换逻辑类似，但如果你不熟悉这种格式，我建议直接编辑文件，把 URIs 指向 https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ 即可。
提示：换源后执行
apt update如果出现Signature或Release file错误，先确认是不是用了 HTTPS 但系统缺少apt-transport-https包。虽然新版自带支持，老版本环境还是要手动装。
2.2 更新慢、update 报错：一次完整的排查链路
如果你已经换了源，apt update 还是慢，那就需要按链路排查了。我遇到过的情况主要有四种。
第一种是源列表里残留了无效源。有些教程会让你加第三方源（比如某个软件的官方源），但你不用那个软件之后，源并没有移除。apt update 会逐个源去拉索引，其中一个超时就会卡住整个流程。排查方法也很简单：
bash复制# 查看所有启用的源
apt-cache policy | grep -A 2 'http' | head -50
# 或者直接看源文件
grep -rh ^deb /etc/apt/sources.list /etc/apt/sources.list.d/
把这些源逐个在浏览器或 curl 里访问一下，哪个打不开，就注释掉哪个。
第二种是 IPv6 惹的祸。部分服务器上，系统默认尝试 IPv6 解析，而当前网络环境的 IPv6 路由不可用，导致请求一直等到超时。我遇到过日本 VPS 上 apt update 卡了 40 秒的情况，就是 IPv6 问题。处理办法是强制 apt 优先 IPv4：
bash复制# 在系统配置里添加 apt 的获取设置
echo 'Acquire::ForceIPv4 "true";' | sudo tee /etc/apt/apt.conf.d/99force-ipv4
第三种是多架构源导致的重复解析。如果你装了 i386 架构的库（比如为了兼容 32 位程序），apt update 会同时对 amd64 和 i386 拉取索引，条目数量翻倍，速度自然慢。
第四种是锁文件和残留缓存问题。Could not get lock /var/lib/dpkg/lock-frontend 这个报错估计大家都见过。通常是之前的安装中断了，或者后台有 unattended-upgrades 在跑。解法是确认没有其他 apt 进程后，删除锁文件，然后修复可能损坏的 dpkg 状态：
bash复制sudo rm /var/lib/apt/lists/lock
sudo rm /var/lib/dpkg/lock
sudo rm /var/lib/dpkg/lock-frontend
sudo dpkg --configure -a
这里要特别说一句：删锁之前一定要用 ps aux | grep -i apt 确认没有进程在跑，否则可能弄坏 dpkg 数据库。
2.3 依赖冲突、残留包与 deb 文件安装
apt 最强大的地方在于依赖自动解析。apt install 会帮你把依赖树全部理清。但依赖出问题时，也是最让人头大的。我在开发中经常遇到下面这几个场景。
场景一：apt install 提示依赖关系不满足，但又不知道缺什么。这时先跑一遍修理工序：
bash复制sudo apt --fix-broken install
sudo apt --fix-missing install
场景二：手动下载了一个 .deb 文件（比如一些商用软件只提供 deb 包），dpkg -i xxx.deb 装不上，报依赖缺失。正确姿势是先装依赖再装包：
bash复制sudo apt install -f
sudo dpkg -i ./xxx.deb
或者干脆用 apt 直接装本地 deb：
bash复制sudo apt install ./xxx.deb
场景三：卸载软件时想把配置文件也清掉。apt remove 只删程序，apt purge 连配置文件一起删。如果你是重装某个服务排查问题，purge 才是真正干净的卸载。
场景四：装了一堆开发库，后来不用了，残留包越来越多。定期执行 sudo apt autoremove 能清掉那些作为依赖被装进来、但现在没用的包。不过执行前最好看一眼它要删什么，以免把还需要的包误删了。我就有一次手滑，把某个项目的运行时依赖给 autoremove 掉了，项目直接跑不起来。
3. 编辑器、编译器和构建工具：真正把代码跑起来的三板斧
3.1 编辑器选型：别把时间浪费在“配置编辑器”上
编辑器这个话题很容易引战，但我只讲实际开发里的选择逻辑。如果你在服务器上操作，没有图形界面，那 vim 是必须会的，没有商量的余地。不必把它配成 IDE，只需要掌握 i 进入插入、Esc 退出、:wq 保存退出、/keyword 搜索、dd 删行，这几招就足够干活了。
本地开发的话，VS Code 配 Remote-SSH 插件是效率最高的组合。它让你在本地界面里写代码，实际编译运行都在远端服务器上，这个模式我用了好多年，比在服务器上直接撸 vim 舒服太多。提醒一下：Remote-SSH 连上后，如果你改了远端的环境变量（比如 ~/.bashrc），记得重启 VS Code 的远程窗口，否则终端里读到的还是旧环境。
3.2 gcc/g++ 四阶段与必须掌握的编译参数
很多教程会把 gcc 当成一个编译器，其实它更像一个编译驱动。一个 C 文件从源码到可执行文件，内部要经过四个阶段：预处理、编译、汇编、链接。
bash复制# 一步到位的方式
gcc -g -Wall -o app main.c util.c
# 如果只看中间产物，可以分步执行
gcc -E main.c -o main.i # 预处理：展开头文件和宏
gcc -S main.i -o main.s # 编译：生成汇编
gcc -c main.s -o main.o # 汇编：生成机器码目标文件
gcc main.o util.o -o app # 链接：合并符号表和库
这里有几个参数是开发必备的：
-g：生成调试信息。没有它，gdb 里你看不到源码和变量名，只能看到一堆汇编地址，调试效率极低。-Wall：打开常见警告。我见过太多人忽略这个参数，结果代码里有未初始化变量、隐式类型转换之类的隐患，编译期没提示，运行期才炸。-O2：开启优化。调试阶段不建议对刚写完的代码开高优化，因为优化会重排指令，gdb 单步时会跳来跳去，看得人发懵。发布前再开-O2做性能验证。-I、-L、-l：指定头文件路径、库文件路径、动态库名。项目一旦引入第三方库，这三个参数就必须搞清楚。我见过有人把-l拼成-1，编译结果一片红。
有一个点容易被忽略：链接时的库顺序。gcc main.o -o app -lpthread 和 gcc -lpthread main.o -o app 结果可能不一样，尤其涉及静态库时，顺序错了就会出现 undefined reference to pthread_create，而代码层面你明明引用了 pthread。原因在于链接器解析符号是单遍扫描，库要放在引用它的目标文件后面。这条经验我至少帮三个人解决了编译报错。
3.3 从 make 到 CMake：工程化的分水岭
当项目只有一个文件时，直接用 gcc 没问题。一旦文件多到几十个，你还用一条 gcc 命令手动编译，那就是给自己挖坑。make 是解决这个问题的经典工具，核心就是一个 Makefile：
makefile复制CC = gcc
CFLAGS = -g -Wall
OBJS = main.o util.o
app: $(OBJS)
$(CC) $(CFLAGS) -o app $(OBJS)
main.o: main.c util.h
$(CC) $(CFLAGS) -c main.c
util.o: util.c util.h
$(CC) $(CFLAGS) -c util.c
clean:
rm -f $(OBJS) app
Makefile 的核心价值是增量编译：哪个源文件改了，就只重编哪一个，不用全量重来。大型项目的构建时间就是这样省下来的。
不过 Makefile 的语法实在反人类，大量项目选择用 CMake 生成构建系统。CMake 的输入是 CMakeLists.txt，语法比 Makefile 友好太多：
cmake复制cmake_minimum_required(VERSION 3.16)
project(myapp C)
set(CMAKE_C_STANDARD 11)
add_executable(app main.c util.c)
target_include_directories(app PRIVATE ${CMAKE_CURRENT_SOURCE_DIR})
使用流程固定三步：
bash复制mkdir build && cd build
cmake ..
make
这里我强烈建议使用 out-of-source 构建，也就是在 build 目录里跑 cmake，而不是在源码目录里直接生成。好处是源码目录干净，不会产生一堆 CMakeCache.txt、cmake_install.cmake 之类的中间产物；想重来，直接删掉 build 目录就行。
4. gdb 调试：从断点到崩溃现场定位的完整思路
4.1 调试前置条件：-g 选项和可读的符号表
gdb 是 Linux 下绕不开的调试器。但 gdb 不是万能的，它依赖编译时生成的调试信息。我刚才反复强调 -g，原因就在这里：不 -g 编译的程序，gdb 能看到函数名和行号，但看不到变量的值，也无法在具体源码行打断点。有些封装严格的发布版程序甚至会 strip 符号表，gdb 只能回答“函数地址在哪”，回答不了“这个变量值是多少”。
我自己排查问题有个原则：编译时永远带 -g -Wall，哪怕发布前忘记去掉，也顶多多占点磁盘，不会影响性能。但反过来想调试时没有 -g，那就真的是无米之炊了。
4.2 基础操作序列：断点、单步、变量与调用栈
用 gdb 调试程序的典型流程，我用下面这个代码说明：
c复制// main.c
#include <stdio.h>
int add(int a, int b) {
int result = a + b;
return result;
}
int main() {
int x = 10;
int y = 20;
printf("before\n");
int sum = add(x, y);
printf("sum = %d\n", sum);
return 0;
}
编译加调试信息：
bash复制gcc -g -o app main.c
gdb ./app
启动后，你在 gdb 提示符下依次执行：
gdb复制list # 查看源码
break main # 在 main 函数入口打断点
run # 运行到断点
break add # 在 add 函数打断点
continue # 继续运行，会停在 add
print a # 查看变量 a 的值
next # 单步执行，不进入函数
step # 单步执行，进入函数
backtrace # 查看调用栈
frame 1 # 切换栈帧
info breakpoints # 查看所有断点
这套流程看着简单，但实际用起来有几个技巧。比如你调试一个循环，只关心第 100 次迭代时的状态，不用手动按 99 次 next，直接：
gdb复制break main.c:10 if i == 100
条件断点在定位复杂 bug 时特别管用。
还有一个我常用的神器：watch。当某个变量被莫名其妙改掉了，你可以在变量上设置观察点，程序一改它就会立即停下：
gdb复制watch sum
4.3 段错误与 core dump：崩溃现场的完整还原
段错误是 Linux C/C++ 开发者的老朋友。遇见 Segmentation fault (core dumped)，很多人第一反应是懵。其实排查思路很清晰：让系统在崩溃时把内存现场保存成 core 文件，然后用 gdb 打开 core，就能直接定位崩溃位置。
默认情况下很多系统不生成 core 文件，需要先开启：
bash复制ulimit -c unlimited
这样设置只对当前 shell 会话有效。想永久生效，需要写在 ~/.bashrc 或 /etc/security/limits.conf 里。不同发行版对 core 文件的存放路径也不一样，有些放在当前目录，有些放在 /var/lib/apport/coredump 里，查找时多加留意。
生成 core 后，用 gdb 一次性定位：
bash复制gdb ./app /path/to/core
(gdb) bt
bt 会打出完整调用栈，崩溃发生在哪个函数、哪一行，一目了然。比如：
code复制#0 0x000055555555518a in add (a=10, b=0) at main.c:4
#1 0x00005555555551c4 in main () at main.c:12
这就是告诉你，main.c 第 12 行调用了 add，传入的 b 是 0，崩溃点在 add 函数第 4 行。接下来看第 4 行在干什么，基本就能定位了。
如果是空指针解引用，bt 可能显示 SIGSEGV，然后你用 frame 0 切到崩溃帧，用 info locals 看局部变量，就能知道哪个指针是空。整个过程我一般控制在三分钟内。
4.4 多线程与 attach 到运行中的进程
现实中的程序很少是单线程的。调试多线程程序，gdb 默认行为是所有线程都会响应条件断点，这会导致调试体验非常混乱。我常用这几个命令：
gdb复制info threads # 查看所有线程
thread 2 # 切换到 2 号线程
thread apply all bt # 把所有线程的调用栈一次打出来
set scheduler-locking on # 切到某个线程后，其他线程不再随意切换
thread apply all bt 是排查死锁问题的救命稻草。死锁发生时程序看起来卡住了，你把所有线程的栈打出来，看每个线程卡在哪个锁上，锁的持有顺序就清楚了。
另一种常见场景是程序已经跑起来了，你不想重启它来复现问题，而是想直接调试正在运行的进程。这时用 attach：
bash复制# 先找到进程 PID
ps aux | grep myapp
# 附加到进程
sudo gdb -p 12345
注意：attach 会暂时停止目标进程，调试完要用
detach让它继续运行，而不是quit。另外，对没有 ptrace 权限的进程，需要加 sudo 或者调整kernel.yama.ptrace_scope参数。echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope可以临时放开。
5. 跨平台与嵌入式调试场景：gdb server 连接失败的排查链路
5.1 could not connect to target：四层排查法
如果你从事嵌入式开发，或者需要调试远程主机上的程序，gdb 的远程调试模式是必经之路。常见的报错就像热搜词里写的：gdb server failed: could not connect to target. please check if target ...。
我总结了一套四层排查法，基本能覆盖这个报错的绝大多数原因。
第一层，网络连通性。先确认目标机 IP 和端口是否可达：
bash复制ping <target_ip>
nc -zv <target_ip> <port>
如果 ping 不通，检查网线、IP 配置；如果 ping 通但端口不通，检查目标机的 gdbserver 是否真的在监听：
bash复制netstat -tlnp | grep <port>
第二层，gdbserver 是否正常运行。在目标机上手动启动 gdbserver 时，典型的命令是：
bash复制gdbserver :2345 ./myapp
如果你在目标板上看到 Process ./myapp created; pid = 123，说明 gdbserver 本身没问题。如果显示 Unable to listen on port，说明端口被占了，换个端口即可。
第三层，调试器与 gdbserver 的架构匹配。gdb 客户端要想连接远程目标，必须是支持目标机架构的版本。比如目标板是 ARM 架构，你本地用 x86 的 gdb 去连，即使网络通了，也会在后续的握手阶段失败。这就引出下一个主题：multi arch gdb。
第四层，防火墙与权限。目标板上如果开了防火墙，gdbserver 监听的端口可能被挡住。嵌入式目标板一般没有系统的防火墙，但在开发机上，ufw 或 firewalld 可能会拦截出去的连接，也值得检查。
5.2 multi arch gdb 与体系结构匹配
很多时候你拿到一个 ARM 架构的目标板，想在 x86 的 Ubuntu 上用 gdb 调试它。这时直接装 gdb 是不够的，因为它只支持你本机的 x86 架构。解决方案有两个：
第一个是安装 gdb-multiarch：
bash复制sudo apt install gdb-multiarch
gdb-multiarch ./myapp
(gdb) set architecture aarch64
(gdb) target remote <target_ip>:2345
gdb-multiarch 的好处是一个 gdb 能支持多种架构，嵌入式调试一把梭。第二个方案是安装交叉工具链里自带的 gdb，比如 aarch64-linux-gnu-gdb。它会默认按目标架构解析调试信息，不用像 gdb-multiarch 那样手动 set architecture。我的经验是：如果工具链已经装好了，直接用工具链自带的 gdb 最省事。
5.3 openocd 场景下的 gdb server 异常退出
嵌入式调试场景里，除了用 gdbserver 在目标系统内起服务，还有一种常见方式是通过 OpenOCD 连接调试器（比如 J-Link、CMSIS-DAP）来调试裸机程序。此时你看到的报错可能变成：openocd: gdb server quit unexpectedly. see gdb-server output in terminal tab for more details.
这个报错表面上是说 gdb server 进程退出了，但真正的问题往往在 OpenOCD 与目标芯片的连接阶段就有征兆。我遇到过的原因有两种：一种是 OpenOCD 的配置文件里片选了错误的适配器接口，比如实际用的是 CMSIS-DAP，却配置成了 J-Link，OpenOCD 在初始化阶段就退出；另一种是端口冲突，OpenOCD 默认占用 3333 端口做 gdb 端口，同时跑了两个 OpenOCD 实例，后一个就起不来。
排查方法是直接在前台运行 OpenOCD，观察完整输出：
bash复制openocd -f interface/cmsis-dap.cfg -f target/stm32f4x.cfg
如果输出里有 Error: open failed，先检查设备是否被其他进程占用。如果输出里显示能连上芯片，但 gdb 一 target remote localhost:3333 就断，多半是 try 次数问题，可以降低 adapter speed 再试。
5.4 老工具在 Linux 上启动问题的经验
除了嵌入式，还有一个高频搜索是关于老版本工具在 Linux 上的启动问题，比如 Xilinx ISE。这类工具大多是在十几年前发布的，当时的主流 Linux 还是 32 位系统。你在 64 位系统上装完，启动时报缺少 libstdc++.so.5、libXm.so.3 这类错误，基本就是缺少 32 位兼容库。解决办法在较新版本 Ubuntu 上可以统一：
bash复制sudo dpkg --add-architecture i386
sudo apt update
sudo apt install lib32z1 lib32ncurses6 lib32stdc++6
这类老工具还有一个常见问题是 Java 版本不匹配。它们内置了特定版本的 JRE，但如果它检测到系统有更高版本 Java，反而会启动失败。一般通过修改启动脚本，把 JAVA_HOME 指向内置 JRE 解决。这类问题虽然不在“从 apt 到 gdb”的主线上，但因为它发生在开发环境搭建阶段，跟工具链配置是同一个套路：先搞清楚报错缺什么，再反查运行环境，最后用 apt 补齐。
6. 开发机上的日常命令与效率习惯整理
6.1 高频命令的框架式记忆法
Linux 常用命令被搜索的次数常年居高不下，但我不建议你去背命令大全，而是按“对象”分类记忆。说白了，Linux 下你操作的对象就那么几类：文件、进程、网络、权限、日志和系统信息。
文件操作的核心是三板斧：ls（查看）、cp/mv/rm（操作）、find（查找）。其中 find 的使用频率极高，比如按名字找文件：
bash复制find /home -name "*.c" -type f
进程类主要命令是 ps、top、kill、htop。排查 CPU 占用时，我一般先跑 top -c 看进程，再跑 ps -ef | grep 进程名 确认命令行参数，最后用 kill -9 结束卡死进程。
网络类用到最多的是 ip addr、ping、ss -tlnp。ss 取代了老旧的 netstat，查看某个端口有没有服务监听：
bash复制ss -tlnp | grep 8080
权限类的高频命令无非就是 chmod、chown、sudo。我给自己立过一个规矩：拿到新环境先看当前用户有没有 sudo 权限，再看需要不需要把常用用户加入某个用户组。
日志类命令的王者是 tail 和 grep。排查服务异常时，三步走：
bash复制tail -n 200 /var/log/syslog # 先看最近的日志
grep -i error /var/log/syslog # 再筛错误
journalctl -u myservice --since "10 min ago" # systemd 服务看这个更方便
6.2 新装系统后必做的几件事
我每次新配一台 Linux 开发机，做的第一件事永远是同一套流程：换 apt 源、更新系统、装开发基础包。这套流程顺序很重要，按我的习惯走完基本不会碰壁。
bash复制# 1. 换源（按前面说的版本区别处理）
# 2. 更新索引和已装软件
sudo apt update
sudo apt upgrade -y
# 3. 安装开发基础包
sudo apt install -y build-essential gdb vim git openssh-server cmake
build-essential 里包含了 gcc、g++、make 等一堆基础工具，一条命令装齐。网络版开发机建议顺手装好 openssh-server，否则远程登录都做不了。git 就不用说了，现在没有版本控制的项目几乎不存在。
如果你的开发语言是 Python，需要注意一个细节：系统自带的 Python 版本通常是给系统工具用的，不要直接在系统 Python 上乱装包，否则容易把系统依赖搞坏。现在流行用 uv 或 conda 管理 Python 环境，装成了再干活：
bash复制apt install python3 python3-pip python3-venv
python3 -m venv .venv
source .venv/bin/activate
6.3 权限、用户管理和文件操作的安全习惯
开发机上常用 useradd 新建用户，但 useradd 和 adduser 的行为差别很大。adduser 是个交互式脚本，会帮你建家目录、设密码、填用户信息；useradd 是底层工具，不加参数默认连家目录都不建。所以我在新环境里习惯用 adduser：
bash复制sudo adduser zhangsan
sudo usermod -aG sudo zhangsan # 把用户加到 sudo 组
文件删除也是一门学问。rm -rf 这条命令的杀伤力，干过 Linux 的人都有体会。我的一条铁律是：在跑 rm 之前，先 ls 确认当前路径和要删的内容。我在生产环境犯过一次错误：在 /var/ 目录下想清一个子目录，结果命令写成了 rm -rf /var /www，虽然最后没有真的执行（因为系统有保护），但那一刻的冷汗让我彻底记住了“永远先 pwd 再 rm”。
还有一个新手非常容易踩的坑：把脚本写好后直接 chmod +x script.sh && ./script.sh 运行。结果脚本里用了 /bin/bash 的语法，但系统的 sh 指向的是 dash，执行报错。我的习惯是脚本第一行明确写 #!/bin/bash，然后显式用 bash script.sh 跑一次测试，再赋执行权限。
再补充一个与工具链相关的习惯：当你在开发机上进行性能测试，或者要同时跑多个 GPU 任务时，nvidia-smi 是不够的，htop 能让你看每核使用率，iostat 看磁盘 IO，free -h 看内存。我自己压测时习惯开一个终端循环记录：
bash复制while true; do nvidia-smi; sleep 5; done | tee gpu.log
这个日志在排查性能波动时非常有用，能帮你回放 GPU 使用状态，而不是靠肉眼盯屏幕。
我个人还有一个习惯跟大家分享：把常用的工具链命令写成一个 shell 脚本，放进 ~/bin 目录，然后把这个目录加入 PATH。比如一键完成“编译 + 启动 gdb 调试”的脚本，或者一键切换 apt 源的脚本。刚开始写这些脚本可能要花点时间，但长期看，省下来的时间远远超过初始投入。毕竟，所谓工具链，不仅是一堆命令的集合，更是你不断优化自己的工作方式，让它越来越顺手的过程。