任何一个运行在用户空间的程序，都不能直接访问硬件设备或随意读写内核管理的关键数据结构。否则，一个有缺陷的普通进程就可能破坏整个系统的稳定性。Linux 解决这一问题的方法，就是将处理器的执行权限严格分为 用户态（User Mode） 和 内核态（Kernel Mode）。用户程序只能运行在受限制的用户态，当它需要执行那些“只有内核有权完成”的操作时——例如从磁盘读取文件、创建新进程、发送网络数据等——就必须通过一个特殊的入口向内核发起请求，这个入口就是 系统调用（system call）。
从程序员的视角看，系统调用看起来就像一般的函数调用：例如 open() 函数打开一个文件，read() 函数读取内容。但在底层，这些 C 库函数（glibc 提供的包装函数）会做好参数准备，然后触发一条特殊的 CPU 指令（在 x86 架构上早些年是 int 0x80，现在普遍是 syscall 指令），这条指令导致处理器从用户态陷入内核态。内核在接管控制权后，会根据传入的调用号（例如 open 对应编号 2，read 为 0）找到对应的内核函数 sys_open、sys_read 等，执行真正的操作；完成后，再将结果返回给用户程序，同时处理器恢复用户态。
这种机制在实用中有一个直接的好处：所有对硬件的访问都被集中在内核中审计和控制。用户程序无法绕过文件系统的权限检查直接读写磁盘扇区，也无法悄悄修改其他进程的内存。系统调用的代价同样值得关注：每一次系统调用都会引发上下文切换和模式切换，相比于普通的函数调用，它的时间开销要大得多。因此，高性能力求减少系统调用次数——例如，通过标准 I/O 库的缓冲区（fread、fwrite 代替逐字节的 read、write），或将多次网络发送合并为一次 sendmmsg 调用。
在日常开发或排查问题时，可以使用 strace 工具来观察一个程序实际发出了哪些系统调用。执行 strace ls ，就会看到 open、read、write、close 等调用和它们的参数、返回值。这是定位“程序卡在什么地方”、“权限是否足够”、“文件是否真被找到”等问题最直接的手段。同样，操作系统也提供了 /proc/<PID>/syscall 等接口，让你可以实时看到某个进程当前正在执行的系统调用。
概括起来，系统调用是用户程序请求内核服务的标准化接口，它用清晰的机制保证了隔离与安全，也用相当直接的方式支撑起整个操作系统上层的一切活动。理解系统调用，就等于理清了用户程序与底层系统之间的“合同”，能帮助你在编程、调试和性能调优时做出更准确的判断。