你需要在传统模式下启动，于是在 BIOS 里把 CSM 改成了「启用」。保存、重启、再进 BIOS 一看——那一项的旁边多了一行小字，大意是「该模块未加载」，或者干脆这个选项又变回了灰色不可用状态。你反复改了几次都是同样结果，仿佛固件在跟你作对。
这不是 bug，也不是你没保存成功。这是固件里一条被写死的互斥规则在起作用。
现象
具体的表现有几种，通常至少命中一种：
- CSM 主开关显示为「启用」，但同页面或提示栏注明「CSM / Compatibility Support Module 未加载」；
- 保存重启后，CSM 又自动回到「关闭」，改不动；
- 更隐蔽的一种：CSM 看着是开着的，但传统启动项始终不出现，行为上等于没开。
只有把因果关系想成「有另一个设置挡在前面」，这些现象才能解释得通。
根因
挡住 CSM 的是安全启动（Secure Boot）。
安全启动的设计目标，是确保引导链上的每一段代码都经过签名验证——从固件本身，到引导程序，到操作系统内核。它要达成这个目标，前提是整条链都走在 UEFI 规范定义的路径上，每一步都有可验证的签名。
而 CSM 的存在恰恰相反：它的作用是绕过 UEFI 规范，去执行那些没有任何签名的传统 Option ROM 和传统引导程序。这两件事在设计目标上直接冲突——如果允许 CSM 加载，安全启动承诺的「每一环都可信」就出现了一个可以绕过的后门。
所以固件厂商的做法是：在代码里写死一条规则——安全启动一旦处于开启状态，CSM 直接不加载。注意这里的措辞：不是「CSM 被设为关闭」，而是「CSM 不加载」。所以界面上 CSM 那个开关值可能仍然显示为「启用」（你确实把它设成了启用），但它对应的模块根本没被固件加载，自然也就不生效。这就是「设了却提示未加载」的来源。
解决
找到安全启动菜单，把它关掉，CSM 才会真正加载。
安全启动（Secure Boot）→ 关闭 / Disabled
CSM（兼容支持模块） → 启用 / Enabled
安全启动的菜单在不同主板上位置不一，通常在 Security、Boot、Authentication 标签下；有的主板还要求先清除已注册的密钥（Clear Secure Boot Keys）或把模式切到「自定义/Setup Mode」，才能把安全启动关掉。
关掉之后回到 CSM 那一项复核一次，确认状态不再是「未加载」。
需要提醒的是：关掉安全启动意味着你放弃了一层引导链完整性保护。如果是自己可控的机器、且确实需要传统引导（比如跑老系统、用老显卡），这是合理的取舍；但如果是面向生产的机器，能走 UEFI 就尽量走 UEFI，不要为了省事关掉它。
延伸与预防
这个案例值得记住的，是那个**「值」与「是否生效」分离**的思维模型。
在很多系统里，「配置项的值」和「该配置是否被采用」是两回事。BIOS 里如此，操作系统里更常见：内核参数被更靠后的参数覆盖、配置文件的某个段落被某个 include 或条件分支跳过、环境变量被更上层的定义遮蔽、容器里挂载的文件盖住镜像里的同名文件。它们的共同特征是——你看到的那个值，未必是最终生效的那个值。
所以遇到「设了却没效果」，一个高效的排查动作是：不问「我设对了吗」，而问「它有没有被加载/采用」。有没有一条更高优先级的规则在覆盖它？有没有一个前置条件没满足？固件里找「未加载」这类提示语，系统里找 --verbose 输出和「被覆盖」的日志，就是顺着这条思路走的。
顺带一提，这个互斥关系还有一层实用推论：如果你的机器同时需要安全启动和一些只在 UEFI 下运行的功能，那么当你发现某个东西「开不起来」时，可以先检查一下安全启动是不是还开着——它经常是那个「看不见的前提」。