代码拆分后是否会重复引入glib？如何避免该问题？

首先明确：大概率会出现重复引入的情况，但不一定会引发编译错误——因为GLib官方头文件本身已经自带了头文件保护（比如#ifndef GLIB_H这类）或者#pragma once，预处理器遇到重复包含时会自动跳过重复的内容。但这不代表我们可以放任不管，过多的重复引入会增加预处理器的工作量，拖慢编译速度，还可能埋下依赖管理的隐患。

下面是具体的预防方案：

1. 给所有自定义头文件加上头文件保护 #

这是C语言拆分代码的基本操作，不管有没有GLib都必须做，避免自定义头文件被重复包含。

比如constants.h的写法：

#ifndef CONSTANTS_H
#define CONSTANTS_H

// 这里放常量定义，比如：
#define MAX_BUFFER_SIZE 1024

#endif // CONSTANTS_H

也可以用更简洁的#pragma once（主流编译器如GCC、Clang、MSVC都支持），效果一样：

#pragma once

#define MAX_BUFFER_SIZE 1024

2. 按需包含GLib头文件，避免冗余 #

• 如果某个头文件不需要直接使用GLib的类型/函数（比如constants.h只是定义宏），完全不用包含<glib.h>，把GLib的包含逻辑放到对应的.c文件里。
• 只有当头文件里必须暴露GLib相关的类型（比如函数参数是GString*、返回值是GString类型）时，才在头文件里包含<glib.h>。

比如utils.h需要用到GString的操作，就包含GLib：

#ifndef UTILS_H
#define UTILS_H

#include <glib.h>

GString* utils_trim_whitespace(GString* raw_str);

#endif // UTILS_H

而main.c只需要包含自定义头文件即可，不用重复包含<glib.h>：

#include "constants.h"
#include "utils.h"
#include "http_func.h"

int main() {
    // ... 逻辑代码
    return 0;
}

3. 用前向声明减少头文件依赖 #

如果头文件里只用到GLib类型的指针（比如函数参数是GString*，不需要访问GString的内部成员），可以用前向声明代替直接包含<glib.h>，进一步降低依赖。

比如http_func.h的写法：

#ifndef HTTP_FUNC_H
#define HTTP_FUNC_H

// 前向声明GString，不用包含整个glib.h
typedef struct _GString GString;

void http_post_request(const char* url, GString* payload);

#endif // HTTP_FUNC_H

然后在http_func.c里再包含<glib.h>来实现具体逻辑：

#include "http_func.h"
#include <glib.h>

void http_post_request(const char* url, GString* payload) {
    // 这里可以正常使用GString的所有API
}

总结 #

GLib自身的头保护会避免重复定义的编译错误，但我们需要通过自定义头保护、按需包含、前向声明这三步，来优化代码的依赖结构，减少不必要的预处理器工作，让代码更易维护。

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