最可靠方式是使用systemd-modules-load.service，通过/etc/modules-load.d/下.conf文件声明模块名；每行一个模块名（不含.ko后缀），名称须与lsmod或/lib/modules/$(uname -r)/中实际文件一致，空行和#开头行被忽略。
Linux 系统启动时自动加载内核模块，最可靠、最主流的方式是使用 systemd-modules-load.service，通过 /etc/modules-load.d/ 下的配置文件声明模块名。其他方法（如 /etc/rc.local 或自定义 init 脚本）在现代 systemd 系统中不是首选，且容易被忽略或失效。
怎么写一个有效的 modules-load.d 配置文件
只需在 /etc/modules-load.d/ 目录下新建一个以 .conf 结尾的文件，每行写一个要加载的模块名（不含 .ko 后缀），空行和 # 开头的注释会被忽略。
- 模块名必须与
lsmod输出或/lib/modules/$(uname -r)/下实际存在的文件名一致（例如ip_vs_rr对应ip_vs_rr.ko） - 不要写路径，只写模块名；
modprobe会自动从modules.dep解析依赖并加载 - 如果模块有别名（比如
8139too是rtl8139的别名），写别名也可以，但建议优先用标准模块名 - 示例：
echo "ip_vs_rr" | sudo tee /etc/modules-load.d/ipvs.conf
为什么 systemctl restart systemd-modules-load.service 有时报错
执行 systemctl restart systemd-modules-load.service 报错，常见原因是模块尚未安装到 /lib/modules/$(uname -r)/，或模块名拼写错误，或模块依赖未满足（比如 ip_vs_rr 依赖 ip_vs，但后者没列在配置里）。
-
systemd-modules-load.service在启动时调用modprobe <module></module>，不检查模块是否存在，只看返回码 - 报错信息通常类似
modprobe: FATAL: Module xxx not found in directory /lib/modules/5.15.0-xx-generic - 验证方式：手动运行
sudo modprobe xxx，看是否成功；失败则用modinfo xxx检查模块路径和依赖 - 模块未安装？确认已运行
sudo make modules_install（自己编译的模块）或安装了对应内核的linux-modules-extra包（Ubuntu/Debian）
哪些情况不能靠 modules-load.d 自动加载
某些模块无法通过静态配置提前加载，因为它们依赖硬件探测结果或用户空间事件，modules-load.d 不适用。
- PCI/USB 设备驱动（如
e1000e、usbserial）：由 udev 根据modules.alias动态触发，无需手动配置 - 需要参数才能工作的模块（如
nf_conntrack_ftp ports=21）：modules-load.d 不支持传参，得改用/etc/modprobe.d/*.conf配置options行 - 被
blacklist屏蔽的模块：即使写进modules-load.d，也会被modprobe忽略（检查/etc/modprobe.d/*.conf中是否有blacklist xxx） - initramfs 阶段就需要的模块（如 LVM、RAID、NVMe 驱动）：必须打入 initramfs，靠
dracut或update-initramfs重新生成镜像
真正关键的是区分“系统级静态加载”和“设备级动态加载”。modules-load.d 只管前者；后者靠内核总线子系统 + udev + modules.alias 协同完成，不需要你干预——除非你发现某个热插拔设备没被识别，那才该去查 modinfo 和 dmesg | grep -i pci。
