这是个在C开发中经常纠结的问题——毕竟C不像高级语言那样有异常机制，所有错误都得手动处理，但也真没必要给每一行函数调用都套上错误检查逻辑。我自己通常遵循这几个原则：

1. 先判断函数是否「真的可能失败」 #

不是所有函数都有失败的合理场景：

• 必须检查：像malloc、fopen、read、write这类和系统资源交互的函数，失败是真实存在的（内存不足、文件不存在、磁盘满等等），必须检查返回值。
• 可跳过检查：比如memcpy、strcpy（前提是你已经确保参数合法，没有越界），只要输入正确就不会失败；再比如往stdout打印的printf，除非stdout被意外关闭，否则几乎不会失败，这种非关键场景可以跳过。

2. 看错误的影响程度 #

如果某个函数失败会直接导致后续逻辑崩溃，或者造成数据丢失、系统异常，那必须检查：

• 比如malloc分配核心业务缓冲区失败，不检查的话后续访问空指针直接段错误，这种绝对要处理；
• 像你给出的fclose示例就非常典型：fclose失败往往意味着之前的写入操作没完成，数据可能没落到磁盘，这种会造成数据丢失的错误，必须捕获并告知用户。

3. 遵循团队/项目的编码规范 #

如果是在要求严格的嵌入式、安全敏感项目里，哪怕是看起来概率极低的错误（比如printf失败），团队可能也要求你做检查；但如果是快速原型或者小工具，只需要把关键路径的错误处理好就行，不用过度纠结。

举几个实际例子 #

必须检查的场景（malloc）

#include <stdlib.h>
#include <stdio.h>

int main() {
    char* buffer = malloc(4096);
    if (buffer == NULL) {
        perror("Failed to allocate memory");
        return EXIT_FAILURE;
    }
    // 后续操作...
    free(buffer);
    return 0;
}

你的fclose错误检查示例（合理且必要）

#define BUFFER_SIZE 256
char error_msg[BUFFER_SIZE];
if (fclose(file) == EOF) {
    sprintf(error_msg, "Error closing %s\n", filename);
    perror(error_msg);
    // 可以根据情况选择退出，或者继续清理其他资源
}

可跳过检查的场景（stdout打印）

printf("Processing completed successfully\n");

这个就算失败，也不会影响程序核心逻辑，用户可能看不到日志，但程序本身能正常结束，所以可以不用检查。

另外补充一点：有些函数的错误可以间接检查，比如你在fwrite之后没立刻检查返回值，那在fclose时检查也是可行的——因为fclose会刷新缓冲区，如果之前的写入有问题，fclose也会返回错误。

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