console_loglevel设为1或0可屏蔽大部分调试警告上控制台，因仅当消息级别≥console_loglevel时才输出；dmesg仍保留全部日志。
console_loglevel 设为 1 或 0 就能屏蔽大部分调试警告
内核打印是否上控制台，只取决于 console_loglevel 和消息自身的日志级别比较结果。调试类警告（如 KERN_DEBUG、KERN_INFO、部分 KERN_WARNING）级别数值 ≥ 4，只要把 console_loglevel 设为 1 或 0，它们就全被过滤掉——不是不生成，是根本不往终端送。
临时生效执行：
echo 1 4 1 7 > /proc/sys/kernel/printk
这行命令把四个值分别设为：当前控制台级别=1（只放 KERN_EMERG 和 KERN_ALERT）、默认消息级别=4、最小控制台级别=1、默认控制台级别=7。注意第一个数字才是关键，后面三个不影响当前行为，但保留默认值可避免意外副作用。
- 设成
0更激进，连KERN_ALERT都不显示，仅剩崩溃级KERN_EMERG可能透出（实际极少触发） - 设成
1是较稳妥的选择，保留最高两级，兼顾安全与可观测性 - 别用
echo 0 > /proc/sys/kernel/printk—— 这会把全部四个值都写成 0，导致minimum_console_loglevel被错误覆盖，后续可能无法调高
/proc/sys/kernel/printk 四个数字到底怎么配
很多人只改第一个数却忽略其余，结果重启后失效或行为异常。四个值顺序固定，必须按位置赋值：
-
console_loglevel：当前生效的控制台阈值，范围 0–7，值越小越严格 -
default_message_loglevel：无显式级别的printk("xxx")默认打到哪一级，一般保持 4（KERN_WARNING）即可 -
minimum_console_loglevel：console_loglevel能被设到的下限，若设太低（如 0），这里也得同步设为 0，否则写入会失败 -
default_console_loglevel：系统重启后console_loglevel的初始值，建议和第一个数一致，避免重启回退
所以生产环境推荐写成：
echo "1 4 1 1" > /proc/sys/kernel/printk
这样既锁死控制台只收紧急消息，又确保下次启动仍维持该策略。
WARN_ONCE 类警告关不掉？试试 clear_warn_once
有些警告用 WARN_ONCE() 或 printk_once() 打印，它们内部有静态标记位，即使 console_loglevel 调高了，只要标记没清，第一次触发后就再不会输出——但你可能正需要它再次出现来复现问题。
这时要手动清除状态：
echo 1 > /sys/kernel/debug/clear_warn_once
- 该操作仅对已触发过一次的
WARN_ONCE生效，未触发的不受影响 - 需确保 debugfs 已挂载（
mount | grep debugfs），且当前用户有写权限 - 没有“全局清空所有 once”的接口，只能逐次触发+清除，适合测试场景
别忘了 dmesg 里其实还留着所有日志
调低 console_loglevel 只影响控制台输出，dmesg 依然能看到完整日志，包括所有被屏掉的调试信息。这点常被忽略，导致误以为日志丢了。
-
dmesg读的是内核环形缓冲区，不受console_loglevel控制 - 缓冲区大小由
CONFIG_LOG_BUF_SHIFT决定，默认通常 16（64KB），刷满会丢老日志 - 如果发现
dmesg也没内容，先检查是否被dmesg_restrict=1拦住（非 root 用户会被禁止读）
真正想彻底禁用某类日志，得从源头入手：改驱动代码里的 pr_debug 为条件编译，或在模块加载时传参关闭调试开关——控制台过滤只是表层止血，不是根治。
