Linux内核是直接管控硬件、分配资源、强制隔离与错误兜底的唯一权威，所有用户程序必须经其许可才能访问CPU、内存、磁盘或网卡。
Linux 内核是系统真正干活的“底层执行者”，不是协调员，而是直接接管硬件、分配资源、强制隔离、兜底出错的唯一权威。所有用户程序——无论你是跑 Python 脚本还是 Kubernetes 控制平面——都必须经它许可才能碰 CPU、内存、磁盘或网卡。
进程调度与隔离：谁在用 CPU、用多久，内核说了算
用户看到的“同时运行多个程序”，其实是内核在极短时间内反复切换进程上下文。它不靠应用程序自觉让出 CPU，而是靠时钟中断强制抢占，再用 CFS（完全公平调度器）算法动态计算每个进程应得的时间片。
- 如果你发现
top里某个进程 CPU 占用率飙高但响应卡顿，大概率是它被调度器降权（比如nice值被调低），而非真的“占满 CPU” -
systemd是第一个用户空间进程，但它本身由内核通过fork()和execve()系统调用启动；没有内核，连 init 都无法落地 - 容器中设置
cpu.quota或 Kubernetes 的limits.cpu，最终都映射为 cgroup 接口，由内核调度器实时 enforce，不是应用层模拟
虚拟内存管理：每个进程都以为自己独占 4GB（或更多）
内核为每个进程建立独立的虚拟地址空间，并通过 MMU 硬件配合页表完成虚拟地址到物理地址的翻译。这意味着两个进程即使用了相同虚拟地址（如 0x7f8a12345000），背后指向的物理内存也完全不同。
- 当出现
Killed process XXX (python) total-vm:XXXXkB, anon-rss:XXXXkB, file-rss:0kB, shmem-rss:0kB日志，说明 OOM Killer 已介入——这是内核在物理内存彻底耗尽前的主动裁决，不是用户程序崩溃 -
vm.swappiness=0并不等于禁用 Swap，只是极大降低换出倾向；真正禁止 Swap 需要swapoff -a或移除 swap 分区 -
/proc/[pid]/maps显示的地址范围，是内核当前为该进程建立的 VMA（Virtual Memory Area）视图，修改它需通过mmap()或brk()等系统调用，不能直接写
VFS 与设备驱动：文件、磁盘、网卡，全被抽象成“可读写的对象”
你执行 ls /dev/sda 或 curl https://example.com，内核全程不关心这是 NVMe SSD 还是 iSCSI LUN，也不管网卡是 Intel e1000 还是 Mellanox ConnectX——它只认统一的 VFS 接口和网络协议栈入口。
-
open("/dev/nvme0n1p1", O_RDONLY)成功，不代表你能直接读裸设备数据；没权限或没加载对应驱动（如nvme模块），会直接返回EPERM或ENODEV - Docker 使用
overlay2存储驱动时，所有镜像层和容器层的合并逻辑，全部走 VFS 层的->lookup和->read回调，内核并不知道你在跑容器 - 执行
modprobe nf_conntrack后，iptables -t nat -A POSTROUTING才能生效——连接跟踪模块是 netfilter 的依赖项，缺一不可，且必须由内核动态加载
真正容易被忽略的是：内核职责之间高度耦合。比如一次 read() 系统调用，会同时触发 VFS 查找、页缓存判断、块设备队列调度、DMA 引擎启动、中断处理、进程睡眠与唤醒——这整条链路没有一处能绕开内核。你以为在操作文件，其实是在和一个实时运行的微操作系统对话。
