推荐采用三层分离目录结构：src/仅放.c文件，include/仅放对外头文件.h，lib/仅放.a和.o文件；该结构明确区分接口与实现，支持清晰的头文件引用（-I../include）、干净的ar打包（cd src后mv .o至lib再ar）及正确链接（-Llib -lxxx）。
静态库项目该用什么目录结构
直接用扁平目录（所有 .c/.h/.o 全塞一个文件夹）不是不能跑通，但很快会失控——尤其是当你开始加头文件依赖、跨平台编译、或让别人接手时。ar 不关心目录，但人关心。推荐按功能分离的三层结构：
-
src/：只放.c文件，不放.h -
include/：只放对外暴露的头文件（.h），不放实现 -
lib/：只放生成的.a和中间.o，不放源码
这种结构能天然隔离“谁该被别人包含”和“谁只是内部实现”。比如 include/mathlib.h 里声明 unsigned long factorial(unsigned int);，而 src/factorial.c 里实现它——调用方只需 #include "mathlib.h"，完全看不到 factorial.c 路径。
头文件路径怎么传给 gcc -c
编译 .c 到 .o 时，如果头文件在 include/ 下，gcc -c 必须知道去哪找 #include "xxx.h"。错用 -I. 是常见坑——它会让 src/factorial.c 里的 #include "mathlib.h" 去当前目录找，而不是 include/。
正确做法是：
- 进
src/目录执行编译 - 用
gcc -c -I../include factorial.c prime.c -
-I../include表示“向上一级进 include 目录找头文件”
别写成 -Iinclude 或 -I./include——路径是相对于你执行命令的当前工作目录，不是相对于源文件位置。
ar 打包时要不要指定路径
ar rcs libmath.a src/factorial.o src/prime.o 可以，但不推荐。原因有两个：
-
ar会把完整路径（如src/factorial.o）存进归档，导致符号表里带斜杠，某些旧链接器可能解析异常 - 后续用
nm libmath.a查看符号时，输出会混着路径前缀，干扰阅读
更稳妥的做法是：
- 先
cd src - 编译完后，把
.o复制到../lib/（或直接mv *.o ../lib/） - 再
cd ../lib，执行ar rcs libmath.a factorial.o prime.o
这样 ar 里存的只是干净的文件名，nm libmath.a 输出也一目了然。
链接时 -L 和 -l 的路径匹配逻辑
gcc main.c -L. -lmath 这条命令里，-L. 告诉链接器“去当前目录找库”，-lmath 告诉它“找名为 libmath.a 的文件”。注意两点：
- 链接器**不会**自动在
lib/子目录里找——-Llib才会去lib/下找 - 库名必须是
libxxx.a格式，-lxxx才能匹配；写成-lmath.a或-llibmath.a都会失败 - 如果
libmath.a在lib/下，就该用gcc main.c -Llib -lmath -o main
最容易被忽略的是：-L 路径必须是链接器实际能访问的路径，不能是相对源码的路径。比如你在项目根目录运行命令，-Llib 就有效；但如果你在 src/ 下运行，就得写 -L../lib。
