为何部分C API不遵循封装原则？附目录文件获取示例

其实这背后主要是几个现实因素的权衡，毕竟C语言本身就是为底层操作、性能最大化设计的，封装有时候就得给这些核心需求让路：

1. 历史遗留与设计哲学 #

C诞生于上世纪70年代，当时的软件运行环境内存极小、性能是绝对的第一要务，而且开发者大多是直接和硬件打交道的工程师。C的设计哲学就是“信任程序员”，不会强行做过度封装，而是把控制权完全交还给开发者。很多早期API都是在这个思路下诞生的，后来为了兼容大量存量代码，也没法彻底重构为完全封装的样式。

2. 性能与内存开销的考量 #

封装往往意味着额外的函数调用、结构体包装或者状态管理逻辑，这会带来一点点性能损耗和内存占用。对于需要频繁调用的底层API（比如文件系统、内存操作），这一点点损耗在大规模场景下会被迅速放大。C选择把这些开销的选择权留给开发者，而不是强制封装增加不必要的负担。

3. 底层访问的必要性 #

很多C API是用来和操作系统内核、硬件直接交互的，这些场景下需要直接操作底层资源（比如句柄、内存地址）。如果做完全封装，反而会限制开发者的灵活性，没法完成一些定制化的底层操作。

举个目录文件获取的例子 #

如果是完全封装的理想设计，你可能只需要调用类似get_all_files_in_dir(const char* path, FileList* out_list)的函数，不用关心内部怎么遍历、怎么管理状态。但C的标准库API（比如POSIX的opendir/readdir）或者Windows的FindFirstFile/FindNextFile却完全不是这样：

POSIX 平台的例子：

#include <dirent.h>
#include <stdio.h>

int main() {
    DIR* dir = opendir("."); // 直接获取目录指针，暴露内部句柄
    if (!dir) {
        perror("opendir failed");
        return 1;
    }

    struct dirent* entry;
    while ((entry = readdir(dir)) != NULL) { // 手动循环读取每个条目，自行管理遍历状态
        printf("%s\n", entry->d_name);
    }

    closedir(dir); // 手动释放资源，没有自动回收机制
    return 0;
}

这里的DIR是一个不透明结构体，但你必须直接持有它的指针，手动调用closedir释放；readdir需要你自己循环处理结果，而不是API一次性返回所有文件列表。这种设计没有把“目录遍历”完全封装成黑盒，而是把遍历的控制权交给了你——比如你可以随时中断遍历，或者在遍历过程中做自定义过滤。

Windows 平台的例子：

#include <windows.h>
#include <stdio.h>

int main() {
    WIN32_FIND_DATA find_data;
    HANDLE hFind = FindFirstFile("*.*", &find_data); // 直接操作句柄和结构体

    if (hFind == INVALID_HANDLE_VALUE) {
        printf("FindFirstFile failed\n");
        return 1;
    }

    do {
        printf("%s\n", find_data.cFileName);
    } while (FindNextFile(hFind, &find_data)); // 手动循环，自行维护数据结构体

    FindClose(hFind); // 手动关闭句柄，需开发者自行管理资源生命周期
    return 0;
}

这里的暴露更直接：你需要自己定义WIN32_FIND_DATA结构体，把它的地址传给API，手动循环调用FindNextFile，最后还要记得关闭句柄。完全没有封装成“传入路径，直接得到文件列表”的简单接口，而是把底层的查找状态、数据结构都摊开给了你。

这种设计虽然牺牲了封装性，但换来了极致的性能和灵活性——你可以在遍历过程中实时过滤文件、提前终止遍历，或者直接操作WIN32_FIND_DATA里的额外信息（比如文件大小、修改时间），而不需要API额外提供一堆 getter 函数。

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