最常见原因是函数调用前未声明或未包含对应头文件：如strlen需#include ，sqrt需#include ，getline需#define _GNU_SOURCE后#include ，且函数名、声明与定义必须严格一致。
函数调用前没声明或没包含头文件
这是最常见原因：编译器在解析到 strlen、getline、sqrt 这类函数时，发现前面既没写函数原型（如 size_t strlen(const char *);），也没 #include <string.h></string.h> 这类头文件，就只能“猜”——C89 允许它假定返回 int，但 C99 及以后标准直接报 implicit declaration of function 'xxx' 警告（加 -Werror 就变错误）。
- 标准库函数必须包含对应头文件：
strlen→#include <string.h></string.h>，sqrt→#include <math.h></math.h>，getline→#include <stdio.h></stdio.h>且需定义_GNU_SOURCE宏 - 自定义函数要么把定义写在
main前面，要么在main上方加函数原型，比如int compute_sum(int, int); - 别依赖
stdio.h“顺带”声明其他函数——stdio.h不声明strlen，stdlib.h也不声明它
用了 GNU 扩展函数但没开宏
getline 和 asprintf 这类函数不是 ANSI C 标准，而是 GNU libc 扩展。即使写了 #include <stdio.h></stdio.h>，默认也不会暴露它们的声明。
- 必须在所有
#include之前定义_GNU_SOURCE，例如：#define _GNU_SOURCE #include <stdio.h>
- 也可以在编译时加
-D_GNU_SOURCE：gcc -D_GNU_SOURCE main.c - 漏掉这个宏，
getline就算函数体存在，编译器也“看不见”它的原型
头文件路径或拼写错误
看起来写了 #include <string.h></string.h>，但实际没生效——可能是路径错、大小写错，或者被条件编译屏蔽了。
- 检查是否误写成
#include "string.h"（双引号会优先查本地目录，而非系统头文件） - 确认没被
#ifdef __cplusplus或其他宏包裹导致跳过 - 用
gcc -E file.c | grep string.h看预处理后这行是否还在 - 第三方库（如 wiringPi）的函数，必须确保已安装头文件，且
#include <wiringpi.h></wiringpi.h>路径正确
函数名拼写不一致或链接缺失
声明、定义、调用三处的函数名必须完全一致（区分大小写），而且链接阶段要能找到函数体。
- 调用
raspi_write，但定义的是raspi_write_data？编译器只认调用点上的名字 - 函数在另一个
.c文件里，但编译时没一起传给gcc，比如只编译了main.c没加gpio.c - 用了
-nostdlib或-nostdinc却没手动补全所有依赖头文件，会导致标准函数也报隐式声明
int（比如 size_t、void *、double），隐式声明会让调用方按 int 解释返回值，结果可能截断、错位、崩溃——而这种问题在简单测试时根本看不出来。** 
