做操作系统这几年，有个朋友问了我一个特别基础的问题：“操作系统到底是什么？”我当时没想太久，直接回了一句：“操作系统本质上是一堆接口的集合。”用户程序要发请求，靠的是系统调用接口；驱动要接硬件，靠的是设备驱动接口；文件系统要藏住磁盘差异，靠的是VFS虚拟文件系统接口；连进程创建、内存分配、线程退出，归根到底都是接口。把这个“接口”想明白了，操作系统的实现思路基本就顺了。
这篇内容适合正在学操作系统、做嵌入式开发、或者平时天天调API但好奇底层怎么工作的朋友。我会从系统调用的设计逻辑讲起，聊到硬件接口怎么揉进内核，再带大家从零手搓一个最小操作系统的接口骨架，最后会把这些年踩过的接口相关的坑拿出来晒一晒。保证全程是干货，没有任何背书的废话。
1. 接口是操作系统的门面——先弄懂“接口”二字的分量
1.1 你每天都在用，却不一定看见过的系统调用接口
很多人第一次接触“操作系统接口”，是在写C语言的时候调用printf。看起来这就是一个普通的库函数，实际上它背后串起了一整条链路：printf先进入C标准库，库函数内部做字符串格式化，然后调用write这个POSIX接口，write再通过libc的封装触发一个系统调用陷入内核，内核找到文件描述符对应的管道、终端或者文件，最后把数据写进设备驱动。整个过程里，用户程序只看到一个write接口，但它跨过了用户态和内核态这道“权限墙”。
这就是操作系统的第一个核心矛盾：用户程序不能直接操作硬件，也不能直接访问内核内部的数据结构，否则一个程序写崩了，整个机器都跟着崩。所以操作系统必须提供一个受控的入口，也就是系统调用接口。接口不是“方便程序员”这么简单，它是安全边界的一部分。你把接口设计得越好，用户程序的自由度越高，同时内核的安全底线就越牢。
我的个人理解是，操作系统的接口设计有点像大公司的对外服务窗口。窗口后面可以改流程、换系统、调人员，但窗口上的服务条款不能随便动。用户今天来办A业务，明天来办B业务，他都得透过这个固定窗口，不能让他直接进后台翻文件柜。内核的接口也是一样，syscall编号就是“业务类型”，参数寄存器就是“申请表单”，返回值和错误码就是“办理结果”。
1.2 接口定义的三大要素：调用约定、参数传递、错误码
既然说接口是契约，那这个契约具体怎么定？我个人拆成三块：调用约定、参数传递、返回值和错误码。
调用约定解决的是“怎么发起调用”的问题。在x86_64架构上，Linux用syscall指令，调用号放到rax寄存器，参数依次放到rdi、rsi、rdx、r10、r8、r9，最多六个参数。要是超过六个参数怎么办？那就用指针指过去，换句话说，把参数打包成一个结构体指针，这在内核接口里特别常见。为什么这么设计？因为寄存器传参最快，不需要访问内存，而且用户态和内核态的栈不通用，少碰内存就少出错。
参数传递要解决的是“数据怎么给内核”。这里面最要命的是指针参数。用户程序传进来一个指针，指向用户态的内存，内核要是直接拿这个指针去读写，那就有安全风险——用户完全可以传一个非法地址，让内核帮忙踩一脚。所以内核里有一个叫copy_from_user和copy_to_user的机制，在拷贝的同时做地址合法性校验。这块是接口定义的隐性要求：接口签名上写着“char *buf”，实际上背后隐含了“这个指针必须指向用户态可读内存”。
返回值与错误码解决的是“结果怎么判断”。内核统一用负数表示错误码，正数和零表示成功。比如read返回-1，同时把errno设置为EINVAL，意思是参数不合法。这个约定看着简单，但它直接决定了上层代码好不好写。你写应用的时候，如果每次调用接口都要猜“到底哪种情况算成功”，那就说明接口设计得不合格。一个合格的系统调用接口，必须让人看一眼返回值和错误码就知道下一步该干什么。
2. 接口实现背后的三个关键设计决策
2.1 稳定压倒一切：一次定义，十年不变
操作系统接口和普通业务接口最大的区别在于：它不能随便改。一个业务API就算有坑，你可以发v2版，让老用户慢慢迁。系统调用接口没有这个条件，因为整个生态都建立在旧接口之上，一旦改了，所有编译好的程序可能一夜之间全崩。
Linux内核在syscall层面有一条铁律：已经发布的系统调用，绝不轻易改变语义。就算实现有bug，也只能在内部打补丁，不能改接口定义。这就导致内核里会有一些看起来“有点怪”但不得不保留的接口，比如某些老系统调用新程序根本不用，但还是得留着，因为老二进制还在跑。这也是为什么Windows有强大的兼容层、为什么很多工业软件跑在旧系统上依然正常——底层接口没变，应用层就不用改。
这个稳定性设计和工程上的“接口幂等性”其实是同一个思维。接口幂等性说的是：同一个请求重复执行多次，结果应该和执行一次一样。操作系统里的很多接口天然就得有这种性质。比如read系统调用，你重复调用它会返回新的数据，这看起来不幂等，但它的失败重试是安全的——如果调用失败，状态不会变得不可收拾。真正的内存映射、文件锁、设备打开这类操作，如果中途失败，内核必须保证不会留下“半初始化”的状态，否则驱动往上层一报错，整个系统都麻了。我见过很多底层开发者写驱动时，第一步就忘了考虑“接口失败后能不能安全重试”，结果上线后偶发崩溃，排查半天才发现是上次操作没回滚干净。
2.2 并发与同步：管程和协程的底层逻辑
接口设计得再漂亮，如果处理不了并发，照样白搭。操作系统里并发最典型的场景就是多个进程同时调用同一个接口，比如同时写同一个文件，或者同时申请同一块内存。内核必须保证这些操作不互相踩踏，于是就有了同步机制。
这里就得说说热词里被反复提到的“管程”。管程（Monitor）和协程都是并发领域的高频词，但很多人把它俩搞混。管程本质上是一种把互斥锁和条件变量打包在一起的高级同步原语。它的核心思想是：共享资源的所有操作都收进管程内部，线程进入管程必须先拿到锁，想等待某个条件就用条件变量挂起。这就把“锁谁、等什么、怎么唤醒”全部内聚到一个模块里，避免散落在各个调用点上的锁逻辑互相冲突。
协程则是另一个维度的事。协程是用户态的合作式调度，它主动让出CPU，而不是被内核强占。操作系统本身不直接感知协程，它只感知线程。协程库通过把多个协程映射到一个或少数几个线程上，在用户态自己切换上下文。这里的关键是，协程切换不能碰内核的调度数据结构，否则一个协程切到一半，内核突然把线程调度走了，就乱套了。所以接口设计要刻意把这些并行细节隔离好：管程解决“共享资源怎么保护”，协程解决“高并发下怎么省线程”。
我自己的体会是，如果只是做业务开发，管程和协程可能只在面试题里遇见。但一旦往底层走，比如写网络中间件、写嵌入式RTOS、写数据库存储引擎，这些东西就是日常操作。你设计的接口如果不能清楚地回答“并发调用时谁排队、谁等待、谁唤醒”，那这个接口上了生产环境就是要出事的。
2.3 性能与安全：每一次接口调用都有成本
接口不是免费的。每调用一次系统调用，CPU都要从用户态切到内核态，保存现场、切换栈、权限级别切换、执行完再恢复现场。这个开销虽然只有微秒级，但高并发的场景下就是实打实的性能损耗。所以操作系统设计接口时要拼命压缩“每调用一次的成本”，比如使用vDSO机制把某些gettimeofday、clock_gettime这类简单接口直接映射到用户态执行，省掉陷入内核的步骤。
更极端的做法是把多次调用合并成一次，减少上下文切换。比如Linux的io_uring就是一次提交一堆IO请求，内核批量处理。这种“批处理接口”本质上是在性能和接口清晰度之间找平衡：普通接口一次干一件事，通用、好理解；批处理接口一次干一堆事，高效、但要求上层逻辑能接受异步完成。
安全是另一个隐形成本。接口每多一个参数，就多一个校验点；每多一个指针，就多一个安全隐患。内核的接口参数校验一直是重中之重，尤其在内核版本迭代后，有些参数组合原本没被覆盖，后来被攻击者挖出来当漏洞利用。所以内核社区对新增系统调用一向非常保守——宁可少一个接口，也不要一个带隐患的接口。我在实际做驱动开发时也守着这个原则：对外暴露的ioctl命令能少就少，能不暴露寄存器操作就绝不多加一个控制命令。
3. 从软件接口到硬件接口——操作系统的另一半
3.1 驱动就是硬件接口的程序化封装
操作系统只靠软件接口肯定活不下去，它得跟CPU、内存、网卡、磁盘、显示屏打交道。而这些硬件之间的连接方式，就是通常说的硬件接口。从PCIe到USB，从GMII以太网口到I2C、SPI，从M.2到RS422，全是物理世界里的“接口”。
操作系统的驱动模块，就是把这些物理接口翻译成软件接口。举个例子，网卡通过PCIe总线挂在系统里，内核里的PCIe驱动枚举设备、分配资源、注册中断，然后向上提供一个net_device接口，协议栈只需要调用ndo_start_xmit这类函数就能发包。上层根本不需要知道数据是走千兆网口还是万兆光纤，这就是一层接口抽象。
写驱动最忌讳的一件事，是把硬件接口的时序细节直接暴露给上层。比如某个芯片要求写寄存器之前先等100微秒，如果上层调用者不懂这个芯片，他就不知道要等，于是就会出问题。正确的做法是驱动内部把时序管理好，对外只留“打开、读写、关闭、控制”几个干净的接口，就像STLINK和JLINK这类调试器，软件层面就几个指令，内部怎么用SWD或JTAG协议跟MCU通信，那是调试器自己的事。
3.2 别被一堆缩写吓住：硬件接口的基本盘
很多新手一看到PCIe、GMII、M.2、RS422这些名词就头大。其实把它们拆开看，本质就是“一条路上有几根线、每根线传什么信号、多快传一次、谁是主谁是从”。
PCIe是当前最主流的高速总线，CPU、GPU、NVMe硬盘都走它。它采用点对点串行连接，每一路叫一个Lane，X1、X4、X16就是通道数。通道越多，总带宽越大。M.2接口本身是物理形态的标准，既可以接NVMe协议的固态硬盘，也可以接SATA协议的固态。所以“mini PCIe和M.2的区别”这个问题，本质上是一个“接口规格”和“协议”的组合问题：mini PCIe是老的封装形态，M.2是新的封装形态，两者不能简单说谁更好，要看主板支持什么协议。
GMII是以太网MAC层和PHY层之间的并行接口，带时钟同步信号，时序参数要求很严格。写GMII接口驱动时最烦的就是时序参数，一不留意采样点就不对，网络直接不通。RS422则是工业现场最常见的差分串行接口，抗干扰能力强，适合长距离传输。调试MCU时接触的STLINK、JLINK，本质上都是把调试命令封装成SWD或者JTAG时序，和上面这些都是同一个道理。
这块经验我反复讲给团队：硬件接口看着高大上，真正写代码时就是读芯片手册、配寄存器、处理中断、控制DMA。操作系统在这里的核心价值就是把复杂的物理时序抽成稳定的软件接口，让上层不要被硬件差异牵着鼻子走。
3.3 MCU里的Flash接口，为什么值得单独拎出来说
热词里有一个很有意思的小问题：MCU内部的Flash是用什么接口访问的？这个问题的答案可以很简单：大部分MCU内部Flash挂在AHB总线上，CPU通过总线直接访问，这条路上一般带Cache和加速器，读比较快；写Flash得先擦后写，擦除和写入都是按扇区或者页操作，延迟比RAM高几个数量级。要注意的是，Flash写入和擦除期间，CPU一般不能从同一块Flash取指令，所以有些MCU的Flash控制器会暂停总线，或者需要把代码拷到RAM里跑。
这块和操作系统接口有什么关系呢？关系大了。操作系统的Flash驱动、bootloader、OTA升级、文件系统的磨损均衡，全部建立在对Flash接口的正确理解上。你如果直接把Flash当普通磁盘做随机写，写不了几次就废了。所以很多文件系统会设计专门的Flash转换层，上层看是普通文件读写，底层已经把落盘策略优化成按块擦写、按页映射。这里面的接口抽象，和前面说的VFS异曲同工。
4. 实操：从零开始手搓一个最小操作系统的接口骨架
4.1 明确目标：最小但五脏俱全
理论知识说再多，不动手写一遍，总感觉隔了一层。我带大家快速过一遍如何从零写一个最小操作系统的接口骨架，目标很简单：能输出字符、能读键盘输入、能创建进程、能退出进程。不需要图形界面，不需要网络协议栈，只要把接口链路打通。
这种“手搓操作系统”的经验对理解接口特别有帮助。很多概念在Linux源码里看，代码量大、宏多、版本多，容易迷路。但是自己写一个简化版，比如基于RISC-V或x86裸机环境下，只需要几十个文件就能把接口主链路跑通。网上有很多开源教学操作系统，比如xv6，就是专门为这个目的设计的，强烈建议去找来读一遍。
4.2 第一步：定义系统调用表
系统调用表是整个操作系统的“总目录”，一张数组，数组下标就是syscall编号，数组元素是函数指针。我习惯先定义一个头文件，把编号和函数原型都放进去。下面是一份极简示例：
// syscall.h #ifndef __SYSCALL_H__ #define __SYSCALL_H__ #define SYS_PRINT 1 #define SYS_EXIT 2 #define SYS_FORK 3 #define SYS_READ 4 typedef long (*syscall_fn)(unsigned long arg0, unsigned long arg1, unsigned long arg2, unsigned long arg3, unsigned long arg4, unsigned long arg5); extern syscall_fn syscall_table[16]; #endif实现文件里把函数指针填进去：
// syscall.c #include "syscall.h" long do_print(unsigned long arg0, unsigned long arg1, ...) { /* ... */ } long do_exit(unsigned long arg0, unsigned long arg1, ...) { /* ... */ } long do_fork(unsigned long arg0, unsigned long arg1, ...) { /* ... */ } long do_read(unsigned long arg0, unsigned long arg1, ...) { /* ... */ } syscall_fn syscall_table[16] = { [SYS_PRINT] = do_print, [SYS_EXIT] = do_exit, [SYS_FORK] = do_fork, [SYS_READ] = do_read, };这里有个容易被忽视的点：为什么统一用六个unsigned long参数？因为这样系统调用入口只需要做一次参数搬运，不管哪个系统调用，参数都是固定格式，分发函数真正执行时再按需做类型转换。这就是接口里的统一约定，能极大减少汇编入口的处理逻辑。
4.3 第二步：实现陷入处理和参数校验
有了表，还得有一个统一的入口。在RISC-V架构下，用户程序通过ecall指令陷入机器模式或监管模式。陷入后CPU会跳到统一的异常处理入口，理论上入口只需要做一件事：从寄存器里取出syscall编号，判断是否合法，然后查表调用。
// trap.c #include "syscall.h" void syscall_dispatch(unsigned long syscall_no, unsigned long arg0, unsigned long arg1, unsigned long arg2, unsigned long arg3, unsigned long arg4, unsigned long arg5) { long ret = -1; if (syscall_no < 16 && syscall_table[syscall_no] != NULL) { ret = syscall_table[syscall_no](arg0, arg1, arg2, arg3, arg4, arg5); } else { // 编号非法，返回错误码 ret = -22; // -EINVAL } // 把ret写回用户态寄存器的某个位置 current_process->trap_frame->regs[10] = ret; }这个dispatch函数就是所有系统调用接口的“总闸门”。这里我特别提一下安全细节：如果当前进程传了一个非法指针进来，内核是不能直接用的。最简单的做法是先在dispatch层做一个粗略的可访问范围检查，如果地址不在当前进程地址空间内，直接返回错误码。虽然真正健壮的内核要做逐页检查，但骨架阶段先把这层“接口边界”立起来，开发后期会省很多事。
4.4 第三步：用串口驱动演示设备接口抽象
系统调用有了，如果没有实际硬件输出，整个系统跑起来什么都看不见。所以我在骨架里加了一个最简串口驱动，把设备接口设计成三个函数：uart_init、uart_putc、uart_getc。这看起来很简单，但它和上层之间的接口约定很重要。
// uart.c void uart_init(void) { // 配置串口寄存器，设置波特率、数据位、停止位 } void uart_putc(char c) { // 等待发送FIFO为空，写入一个字符 // 例如轮询状态寄存器，直到TX_READY置位 } char uart_getc(void) { // 等待接收FIFO有数据，读一个字符 // 如果缓冲区空，可以返回-1，也可以阻塞等待 }驱动写完后，所有上层要输出文字，都统一走一个“控制台接口”，比如console_putc、console_printf。这样以后要把输出从串口换成显示器，只需要改这个接口的实现，不需要改上面的系统调用层。我在实际项目中见过很多直接把uart_putc调用散落在内核各处的写法，等到要接LCD时，一个个改到想哭。接口抽象的价值，真要到改动的时候才体现出来。
4.5 第四步：最小shell和进程接口
有了输入输出接口之后，就可以做一个最简shell：循环读字符，遇到回车就解析命令，然后调用syscall。比如输入“print hello”，shell就把hello当成参数传给SYS_PRINT；输入“fork”，就创建一个子进程，父进程打印“parent”，子进程打印“child”。
这套流程其实就是整个操作系统的缩影：shell是用户态程序，它不直接碰硬件，只通过系统调用接口发请求；内核收到请求后，找到串口驱动，操作寄存器，完成输出；然后返回结果给shell。接口在这里把用户态和内核态隔开，所有底层细节都被藏起来了。
我在做这个实验时最大的收获是：当时反复调整syscall入口的汇编代码，发现每次都纠结“保存哪些寄存器”，直到我把trap_frame结构体定义成“和硬件上下文一一对应”的形态，才彻底解决。这其实就是接口设计里最核心的思想：让对方只遵守一个约定，所有信息都按这个约定摆放，双方都省心。
5. 接口设计与实现中的常见问题与排查实录
5.1 典型问题速查表
在接口这块踩过的坑，我列了一个速查表，不管是做操作系统内核接口，还是平时做API接口，都有参考价值。
| 症状 | 根因 | 排查方法 | 最佳实践 |
|---|---|---|---|
| 调用接口后偶发崩溃 | 参数指针未校验，内核或服务端访问了非法内存 | 打开地址检查、开启KASAN | 所有指针参数统一走校验入口 |
| 死锁，接口卡住不返回 | 锁顺序不一致，两个路径以不同顺序拿锁 | 打印锁状态、画出锁依赖图 | 定义全局锁顺序，禁止乱序 |
| 返回乱码、错误码不稳定 | 返回值的符号约定不统一，有的地方用-1，有的用NULL | grep错误处理分支 | 固定用负数表示错误码，正数和0表示成功 |
| 高并发下偶发重复扣款/重复写数据 | 接口没有做幂等处理 | 加请求ID，日志对比重复请求 | 对关键接口设计幂等键 |
| 老版本程序跑在新内核上崩了 | 接口语义悄悄变了，或者新增参数没有按向后兼容处理 | 用ABI兼容性工具检查 | 变更接口时必须保留旧的入口路径 |
这和常见的接口压力测试也有直接关系。接口压测不是测它“能扛多少QPS”，更重要的是在高并发下找出隐藏的并发问题、超时问题、资源泄漏问题。做操作系统里的接口也一样，我常对团队说：压测不是为了给领导看数字，是为了逼出那些只在极高并发下才出现的竞争条件。多写一些随机并发的测试程序去调用系统调用，往往比手写一万行静态代码更能发现bug。
5.2 一个典型的死锁排查故事
有段时间我写驱动时，遇到一个特别隐蔽的死锁：一个线程在调用设备控制接口时拿了一把锁A，然后又去拿锁B；另一个线程走的是另一条路径，先拿锁B再拿锁A。两个线程碰一起，互相等对方释放，整个系统卡死。最坑的是，这个概率很低，压力测试跑半天才浮现一次。
锅不在锁本身，锅在接口设计时没做“锁顺序约定”。后来我把所有锁列了个全局顺序表，任何一个路径必须按顺序拿锁，问题再没复现过。这背后的经验是：接口不只是函数签名，它隐含了对资源获取顺序的约束。如果一个接口内部要拿多个锁，一定要在文档或者注释里写清楚锁顺序，否则后来维护的人容易踩雷。
5.3 接口失败后的重试陷阱
另外一个高频事故是重试。网络接口讲究超时重试，比如调用支付类API时，如果响应超时，业务方一般会重试。但重试时必须保证接口是幂等的，否则用户可能被扣两次款。操作系统内部也有类似场景：比如驱动发送网络包超时后要重试，如果重试前没有清理上一次DMA描述符，就可能导致数据错乱。
我个人的习惯是：所有可能重试的操作，在接口设计阶段就要留一个字段或者标志位，专门记录“这是第几次尝试”，让逻辑上能区分“首次执行”和“重试执行”。这比事后再补一个幂等表要靠谱得多。接口重试的时机也很讲究，不是越快越好，要有退避策略。就像系统里的中断处理，如果中断不停重入，CPU直接被打满，所以会有中断抑制和中断合并机制。这种“重试要有节奏”的思想，从上到下都是相通的。
5.4 版本兼容：接口的“慢性病”
接口还有一个躲不开的问题：版本演进。比如微信支付接口更新版本后，老接口往往要保留很长时间，因为商户端升级没那么快。操作系统也是同理，Linux的很多老系统调用可能不太常用，但为了兼容老程序，不能随便移除。
做接口版本兼容时，最怕“改着改着一个bug修好了另一个接口又坏了”。我建议在内部画一张接口依赖图，清楚标出哪些接口被谁调用、哪些接口共享底层资源。这样改一个接口时，可以顺手把所有下游影响点都过一遍。很多底层系统出问题，根本不是新代码写得不对，而是改接口时没考虑到旧调用方的假设。
6. 接口思维对现代开发者的启示
6.1 上层API和内核接口是同一套思维
很多人觉得“操作系统接口”离自己很远，毕竟平时写代码调的都是HTTP API。但我想说的是，上层API的设计逻辑和内核接口其实一模一样：需要定义参数、需要处理错误码、需要考虑幂等、需要做压力测试、需要做版本兼容。
比如前端调一个下单接口，后端返回超时，前端自动重试了一次，结果用户被下了两单。这其实就是接口没有设计好幂等机制，责任在后端接口。和操作系统一样，API接口出了问题，不能都指望调用方“聪明点”，接口实现方必须自身足够健壮。好的API应该像好的系统调用一样，怎么调用都不会让系统陷入不确定状态。
所以如果你之前只写过业务代码，我强烈建议找一段时间好好看看操作系统里的接口设计。这不是要你去写内核，而是要把这套“通过接口隔离变化、通过契约保障稳定、通过幂等应对重试”的思维方式迁移到日常开发中，会少踩很多“线上事故”。
6.2 国产操作系统的生态适配，本质上是接口兼容工作
现在国产操作系统越来越多地出现在日常设备里，很多人问“国产系统和Linux什么关系”。从技术角度看，这些系统大多基于Linux内核或者类Unix内核，关键落脚点就是接口兼容：内核对外提供的系统调用接口和应用层所依赖的运行时接口都要对齐，上层软件才能无缝跑起来。
接口兼容这件事远没有想象中容易。同一个语义的接口，可能因为内核版本不同、库版本不同，实际行为有细微差异。国产系统的团队要做的事，就是在接口层面保证这些差异不会伤害上层应用。这也是为什么驱动开发在系统生态里特别吃香——驱动就是硬件接口和软件接口的翻译层，把一头一尾接好了，整个系统才能转起来。
6.3 学习操作系统的接口，我的推荐路径
如果看到这里，你觉得想进一步深入，我给你一条亲测可行的路径。第一，虚拟化：与其在真实机器上折腾，不如直接用QEMU跑教学操作系统，比如xv6，把它的syscall表和trap处理代码反复读几遍，边读边改，编译运行看结果。第二，驱动：找一块常见的开发板，从GPIO驱动开始写，逐步写UART、I2C、SPI，把硬件接口到软件接口的映射这条路走通。第三，实战：尝试给你的教学操作系统加一个系统调用，比如获取当前进程PID、打印内核日志，跑一个用户程序来验证。做完这三步，你对“操作系统的接口与实现”的理解会提升一大截。
我个人在实际操作中最大的体会是：接口设计里没有“差一点也没关系”这回事。一个参数校验漏了，一个错误码语义含糊，一次重试没有考虑幂等性，都会在不知道哪个深夜以线上事故的形式冒出来。做接口的人，本质上是在和不确定性做对抗。你要是喜欢那种“签好契约，按规矩办事”的工程风格，操作系统是最能给你这种满足感的地方之一。
最后再分享一个小技巧：写接口之前，先花二十分钟把调用方的代码样例写出来。如果调用方写起来很别扭，说明接口设计有问题，该改的是你，不是对方。这条规则在写系统调用、写驱动、写业务API时全能套用，比任何架构理论都实在。
