函数声明必须统一放在头文件中并被所有使用源文件包含，定义只能出现在一个.c文件里；编译多个源文件需全部列出或分步编译链接，否则报undefined reference或conflicting types。
多个 .c 文件里怎么写函数声明才不会报错
Clang 编译多个源文件时，函数声明本身不“写错”，但位置和一致性错了就会报 undefined reference 或 conflicting types。核心原则是：**声明只管类型，定义只许一处；头文件是声明的唯一可信来源**。
常见错误现象：ld: symbol(s) not found for architecture x86_64（链接失败）、error: conflicting types for 'foo'（类型不一致）。根本原因往往是：在某个 .c 文件里写了“假声明”（比如没加 extern 且没定义），或头文件没被所有用到该函数的源文件包含。
- 所有跨文件调用的函数，声明必须统一放在一个
.h文件中，例如utils.h - 每个用到该函数的
.c文件开头都要#include "utils.h"（注意双引号，不是尖括号） - 函数定义（带函数体）只能出现在**一个**
.c文件里，比如utils.c，不能在头文件里写实现 - 如果函数只在单个
.c文件内使用，直接写成static，不用声明进头文件
Clang 命令行编译多个 .c 文件时要传哪些参数
Clang 不会自动合并或查找依赖，你得把所有需要参与链接的 .o 文件或源文件一次性列全。漏掉任何一个定义了函数的 .c 文件，就必然 undefined reference。
推荐做法是分两步：先编译为对象文件，再链接。这样能复用、也容易定位问题：
clang -c main.c utils.c -o main.o utils.o clang main.o utils.o -o program
也可以一步到位（适合小项目）：
Clang 22.1.3
下载
Clang 22.1.3 Windows 64 位历史版本安装包，适合旧项目兼容、LLVM/Clang 工具链回退、编译行为对比、链接问题复现和 C/C++ 构建环境维护。
clang main.c utils.c -o program
- 不要只编译
main.c然后指望它“找到”utils.c里的函数 —— Clang 不做隐式依赖扫描 - 如果用了
-std=c17或-Wall，确保所有.c文件都用相同标准编译，否则可能因隐式函数声明（C89 风格）导致类型冲突 - 避免在命令行里混用
.c和.o（比如clang main.c utils.o），除非你明确知道utils.o已按相同 ABI 编译
头文件里声明函数要注意什么细节
看似简单，但几个细节一错就引发链接或类型错误：
- 函数声明末尾必须有分号，
int add(int a, int b);—— 少了分号，Clang 报expected ';' after function declaration - 参数名在声明里可省略，但类型必须完整，比如
void process(const char *buf, size_t len);不能写成void process(char *, int);（size_t和int在不同平台宽度不同） - 如果函数不接受参数，务必写
void，即int init(void);—— 写成int init();是旧式声明，在 C23 中已废弃，Clang 默认警告 - 用
#ifndef UTILS_H/#define UTILS_H/#endif包裹头文件，防止重复包含导致重定义
为什么有时候加了头文件还是报 undefined reference
最常被忽略的是：**头文件里只有声明，没有定义；而定义所在的 .c 文件根本没参与编译链接**。
检查顺序建议：
- 确认
main.c确实#include "utils.h"，且路径正确（比如当前目录下真有这个文件） - 确认
utils.c文件存在，并且它的函数名、参数、返回值和utils.h中声明完全一致（大小写、const、指针层级都不能差） - 运行
clang -E main.c | grep add（假设函数叫add），看预处理后是否真包含了声明 - 用
nm utils.o | grep add检查utils.o里是否有未定义（U）或全局定义（T）符号 —— 如果是U，说明utils.c里也没定义它
函数声明本身没玄机，麻烦永远出在“谁看见了声明”和“谁提供了定义”的匹配上。头文件不是魔法，它只是让多个编译单元看到同一份契约。契约写了，还得有人履约，而且履约者得被 clang 看见。
