3. 启动参数的作用域与优先级

配置启动参数，最让人头疼的是什么？我个人觉得，就是搞不清「这个参数到底管不管用」。明明配了，系统却不认；或者两个地方都配了，到底听谁的？

这一章，我们就来彻底理清启动参数的作用域和优先级。说白了，就是搞清楚「参数在哪个阶段生效」以及「冲突时谁说了算」。

3.1 参数的作用域：参数在哪个阶段生效？

启动参数不是一配好就全局通用的。它像接力赛，在不同阶段由不同选手负责。我习惯把启动过程分为三个阶段：

• 引导加载器阶段（如 GRUB、U-Boot）
• 内核初始化阶段（Linux Kernel）
• 用户空间阶段（Systemd、init 脚本）

每个阶段能识别的参数类型不一样。你想想看，在 GRUB 里配的参数，Systemd 根本看不见；反过来，Systemd 的配置文件，内核也不会去读。

举个例子，我在项目中遇到过一个问题：同事在 /etc/sysctl.conf 里配了内核参数，但重启后没生效。查了半天才发现，这个参数需要在 GRUB 命令行里通过 kernel 行传递，因为它在内核初始化早期就需要被读取。用户空间的 sysctl 根本来不及。

3.2 参数优先级：冲突时谁说了算？

同一个参数，可能在多个地方出现。这时候就需要一套「谁大谁说了算」的规则。我总结了一张优先级表，你直接收藏就行：

优先级（高 → 低）	配置位置	典型示例	作用域
1（最高）	引导加载器命令行	GRUB 的 linux 行追加参数	内核初始化
2	内核编译内置配置	CONFIG_CMDLINE 编译选项	内核初始化
3	设备树（Device Tree）	chosen/bootargs 节点	内核初始化
4	引导加载器配置文件	grub.cfg 中的 set 命令	引导加载器
5	用户空间配置文件	/etc/default/grub、/etc/sysctl.conf	用户空间
6（最低）	运行时动态修改	sysctl -w、echo > /proc/sys/	运行时（临时）

3.3 优先级冲突的实战案例

光讲理论不够，我们来看一个真实场景。假设你想设置内核的 quiet 参数来减少启动日志：

1. 你在 /etc/default/grub 中写了 GRUB_CMDLINE_LINUX="quiet"
2. 运行 update-grub 后，这个参数被写入了 grub.cfg
3. 但启动时，你在 GRUB 菜单按 e 编辑，手动删掉了 quiet

结果是什么？系统启动时依然会输出大量日志。因为手动编辑的命令行优先级高于配置文件。嗯，这里要注意：手动编辑只在本次启动有效，重启后又会回到配置文件的值。

3.4 参数传递的完整链路

为了让你更直观地理解参数从配置到生效的完整过程，我画了一张流程图：

从这张图可以看得很清楚：参数从用户配置出发，经过引导加载器，再到内核命令行解析，最后分流到内核内置参数、设备树参数和模块参数。每个环节都有机会修改或覆盖参数值。

3.5 如何查看当前生效的参数？

理论讲完了，来点实操。怎么确认系统到底用了哪些参数？我常用的方法有这几个：

• 查看内核命令行：cat /proc/cmdline —— 这是最终传递给内核的参数，最权威。
• 查看引导加载器配置：GRUB 的话看 /boot/grub/grub.cfg，U-Boot 用 printenv bootargs。
• 查看运行时参数：sysctl -a 可以列出所有可调的内核参数。

3.6 常见优先级问题排查

最后，我整理了几个常见问题，你遇到时可以对照排查：

现象	可能原因	排查方法
参数配了但没生效	被更高优先级的配置覆盖	检查 /proc/cmdline 确认最终值
手动修改后重启失效	未固化到配置文件	使用 update-grub 或保存环境变量
参数在 GRUB 中无效	参数名拼写错误或内核不支持	查阅内核文档确认参数名
设备树参数不生效	设备树未正确加载或节点路径错误	使用 dtc 反编译设备树检查

嗯，这一章的内容就到这里。记住一句话：参数的作用域决定它能影响谁，参数的优先级决定冲突时谁说了算。搞清楚了这两点，配置启动参数就不再是玄学，而是有章可循的工程实践。