要看内核里此刻到底加载了哪些模块，最直接、也最可靠的就是lsmod。它会读取/proc/modules，并输出模块名、大小（字节）以及Used by（引用计数和依赖模块）这些关键信息。不过要特别注意，Used by显示为0，并不等于这个模块就是空闲的；另外，模块名本身不带.ko后缀，而且大小写是严格区分的。真要做过滤，最好配合awk+grep正则来处理，这样更不容易漏掉目标。
直接用 lsmod 查当前已加载的模块
lsmod 是唯一能告诉你“此刻哪些模块真正在内核里跑着”的命令。它读的是 /proc/modules，不是磁盘上的文件列表，所以结果反映的是真实运行状态。
- 执行
lsmod就能看到三列：模块名、字节数大小、Used by（引用计数 + 依赖模块名） Used by列数字为 0 ≠ 模块空闲——比如nvidia正在渲染画面时，Used by可能是 0，但rmmod nvidia仍会失败，报错Module nvidia is in use- 模块名不带
.ko后缀，也不含路径；insmod ./hello.ko加载后，在lsmod输出里只显示hello，除非模块代码里写了MODULE_ALIAS
lsmod | grep 过滤时总找不到？注意模块名变体和大小写
直接 lsmod | grep nvme 可能漏掉 nvme_core 或 nvme_pci，因为驱动常拆成多个关联模块。
- 稳妥做法是：
lsmod | awk '{print $1}' | grep -E '^(nvme|nvidia|usb|vfio)'—— 先取第一列模块名，再用正则匹配常见前缀 - 模块名严格区分大小写：
NVIDIA和nvidia是两个东西，实际加载名永远小写 - 闭源模块（如
nvidia）若被标记为 tainted，lsmod默认不显示T标志，得看/proc/modules原始行末尾才有
确认模块是否“可用”而非“已加载”，用 modprobe -l
lsmod 只管内存里的，而 modprobe -l 列的是磁盘上所有预编译好的 .ko 文件路径，适合查“系统有这个模块但没加载”的情况。
modprobe -l | grep ^/lib/modules/$(uname -r)/kernel/drivers/net/ | head -5可快速定位网卡驱动位置- 输出路径含压缩后缀（如
.ko.xz）说明模块被压缩存储，modprobe加载时自动解压，insmod不能直接处理这类文件 - 如果
modprobe -l | grep xxx无输出，但你知道模块应该存在，大概率是depmod -a没跑过，或/lib/modules/$(uname -r)下根本没对应目录
模块加载失败？别只盯 lsmod，要配合 dmesg | tail 和 modinfo
lsmod 空了不代表没试过加载——失败的模块根本不会出现在里面。这时候得看内核日志和模块元数据。
dmesg | tail -20通常包含最近加载失败的提示，例如Unknown symbol in module表示依赖缺失，Operation not permitted往往是模块签名验证失败（CONFIG_MODULE_SIG_FORCE开启）modinfo xxx能确认模块是否存在、路径对不对、有没有depends:字段——比如modinfo veth显示依赖cfg80211，那得先确保后者已加载modprobe --showconfig | grep -A5 xxx查该模块是否被blacklist或install指令覆盖，这是“明明有模块却死活不加载”的高频原因
lsmod 输出里——它可能根本没被调用，可能加载失败被内核拒之门外，也可能被配置规则静默拦截。盯着 lsmod 本身，永远只能看到冰山浮出水面的那一角。 
