系统程序员选择使用system call还是library function的判断标准是什么？

系统工具（ls、who、more等属于这类）选择库函数还是系统调用，本质是在可移植性、功能灵活性、性能开销、行为可控性四个维度做权衡，没有绝对通用的规则，但有明确的优先级判断逻辑：

• 第一优先级：是否有未被库函数封装的内核专属功能需求
  如果要实现的能力是标准库没有暴露的，比如获取文件inode元信息、设置文件描述符特殊标志（如O_DIRECT直接IO、O_NOATIME不修改访问时间）、操作进程权限/信号处理的底层逻辑，直接选择系统调用。比如ls要读取文件的硬链接数、块分配信息，标准C库的普通文件操作接口拿不到对应数据，必须直接调用lstat/stat系统调用，这种场景没有选择空间。
• 第二优先级：是否有跨平台兼容要求
  如果你的工具需要在不同Unix-like系统（Linux、FreeBSD、macOS等）甚至Windows平台运行，优先选择POSIX标准定义的库函数，比如fopen/fread/fclose这类接口，不同平台的libc会帮你做底层系统调用的适配，无需自己为每个平台写兼容代码。如果是仅针对特定内核版本开发的定制化工具，直接调用系统调用更直接。
• 第三优先级：性能与IO模型要求
  系统调用每次执行都需要用户态到内核态的上下文切换，有固定开销。标准库的IO类函数大多自带用户态缓冲区，批量读写场景下可以大幅减少系统调用次数，比如more逐页读取大文本文件时，用fgets比直接调用read每次读一行的效率高很多。但如果你需要实现非阻塞IO、异步IO，或者要完全自主控制缓冲区刷新时机，直接调用系统调用更可控，不会被libc的默认缓冲逻辑引入意外问题。
• 第四优先级：资源操作的细粒度要求
  如果需要在多进程间传递文件描述符、通过fcntl修改文件描述符属性、或者处理信号中断场景下的原子操作，直接使用系统调用返回的文件描述符比用库函数封装的FILE指针更灵活。如果要操作FILE指针内部的文件描述符，还需要额外调用fileno接口，还要额外处理用户态缓冲和内核状态不同步的问题。

实际开发中大多是两者混用的，比如GNU版ls，读取目录结构用libc封装的opendir/readdir（内部调用getdents系统调用），读取普通文件内容用标准IO库函数，获取文件元数据时直接调用lstat系统调用，完全按需选择，没有非用某一类接口的限制。

内容的提问来源于stack exchange，提问作者decuser