董云舟1. 先说清楚：动态库和静态库到底在解决什么问题
每个写过一段时间 C/C++ 的人，迟早都会碰到“怎么把我的代码给别人用，但不想公开源码”这种需求。把 .c 文件直接发给对方是最蠢的做法，稍微有点规模的项目都不会这么干。这时候就需要把代码编译成二进制产物交付，而这个产物无非就是两种形态：静态库和动态库。
静态库在 Windows 下通常是 .lib 文件，在 Linux/macOS 下是 .a 文件；动态库在 Windows 下是 .dll 文件，在 Linux 下是 .so 文件，在 macOS 下是 .dylib 文件。名字不同，本质相同——它们都是“别人能调用、但不能直接看到源码”的编译产物。区别在于链接时机和运行方式：静态库在链接阶段被整体复制进可执行文件，动态库则是在程序启动或运行过程中才被加载。
我经常用“点外卖”来比喻这两者的差别。静态库像是你自己在家做了一顿饭，食材（代码）已经完全变成成品（可执行文件）的一部分，端上桌就能吃，不需要再依赖任何外部东西。动态库则像是点外卖，你手里只有餐具和胃口（主程序），菜（动态库）是商家做好后送到你门口的，如果商家倒闭或者送餐路上出问题，你这顿饭就吃不成。这个比喻虽然粗糙，但能帮初学者快速建立直觉：静态库追求独立性，动态库追求灵活性和共享性。
这篇文章我打算从实际工程的角度，把静态库和动态库从原理到创建再到链接避坑完整讲一遍。内容会覆盖 Linux 和 Windows 两条主流平台，也会提到 Qt/qmake、STM32 这类典型场景下怎么用，以及 onnxruntime 这种第三方库动态库的正确打开方式。不管你是刚学 C/C++ 的学生，还是已经在写业务代码但一直没搞懂库机制的后端/客户端开发，这篇文章应该都能帮你把这块知识拼图补上。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 静态库的编译过程与创建实操
2.1 静态库的本质：就是一组目标文件的打包
静态库听起来很神秘，拆开看其实特别朴素。一个 C/C++ 源文件经过编译后会生成一个目标文件（Windows 下是 .obj，Linux 下是 .o），目标文件里存放的是机器码、符号表、重定位信息这些内容。静态库做的事情，就是把一组目标文件用 ar 命令打包成一个归档文件，仅此而已。
你用压缩软件把 10 个文件压成一个 zip，和编译器把 10 个 .o 文件打包成一个 .a/.lib，这两件事在思路上几乎没有区别。所以静态库本身不做链接，它只是“目标文件的收纳盒”。真正的链接发生在你编译主程序的时候，链接器会把静态库里被引用到的目标文件挑出来，复制进最终的可执行文件。
这里面有一个很重要的点：链接器只会把被引用到的目标文件拉进来，而不是把整个库全部塞进去。 这也是为什么你链接静态库时经常能看到“未解析的外部符号”报错——如果某个目标文件里的函数没人调用，链接器根本不会管它；但如果主程序调用了某个函数，而链接器在所有输入的目标文件和库中找不到这个符号的定义，就会报错。
2.2 Linux 下用 gcc 和 ar 创建静态库
在 Linux 上创建静态库的完整流程分三步：编译、打包、验证。
假设我有两个源文件 math_utils.c 和 string_utils.c，以及对应的头文件 math_utils.h、string_utils.h。第一步先编译出目标文件：
bash复制gcc -c math_utils.c -o math_utils.o
gcc -c string_utils.c -o string_utils.o
-c 参数表示只编译不链接。这一步会生成两个 .o 文件。注意，如果代码里用了比较新的指令集特性，编译时最好加上 -O2 之类的优化选项，否则后面做性能测试时可能会得出错误结论。但这不影响库的生成逻辑。
第二步用 ar 命令打包：
bash复制ar rcs libmyutils.a math_utils.o string_utils.o
参数解释一下：r 表示往归档文件中插入文件（如果已存在则替换），c 表示创建归档文件时不输出多余警告，s 表示生成索引表（相当于给这个打包文件建立目录，方便链接器快速查找符号）。libmyutils.a 这个命名有讲究——Linux 约定静态库必须以 lib 开头、以 .a 结尾，虽然这不是硬性规定，但如果不遵守这个约定，后面用 -l 参数链接时就会出问题。
第三步验证一下库是否正常：
bash复制ar t libmyutils.a
nm -s libmyutils.a
ar t 列出归档文件里包含哪些目标文件，nm -s 显示符号表。如果你能在这里看到自己写的函数名，说明库基本成型了。
2.3 Windows 下用 Visual Studio 创建静态库
Windows 下的静态库创建通常不直接敲命令行，而是通过 Visual Studio 的项目属性来配置。创建一个“静态库”项目后，把所有源文件加进来，编译后会直接生成一个 .lib 文件。
关键点是项目属性里的几个设置。在“配置属性 -> 常规 -> 配置类型”中要选择“静态库(.lib)”。在“C/C++ -> 代码生成 -> 运行库”中，建议先搞清楚自己要用的运行时库类型：/MT 表示静态链接 CRT（C 运行时库），/MD 表示动态链接 CRT。这个选择和主程序项目必须匹配，否则链接阶段可能出现一堆 LNK2005 或者 LNK2038 错误。我在实际项目中踩过这个坑，两个项目一个用 /MT 一个用 /MD，链接时报了一堆重复符号错误，最后花了大半天才排查出来。
如果更喜欢命令行方式，lib.exe 命令也可以用来创建静态库：
code复制lib /OUT:myutils.lib math_utils.obj string_utils.obj
这个命令和 Linux 下的 ar rcs 作用类似，不过 Visual Studio 的编译器通常会用 cl.exe 配套完成编译。
2.4 链接静态库时的常见抉择
用静态库链接主程序，Linux 下可以写成：
bash复制gcc main.c -I./include -L./lib -lmyutils -o app
-I 指定头文件路径，-L 指定库文件路径，-lmyutils 会去 -L 指定的路径下找 libmyutils.a。注意 -lmyutils 对应 libmyutils.a，这里把 lib 前缀和 .a 后缀都省略了，这是 GCC 的命名约定。
Windows 下如果用的是 Visual Studio 命令行，对应的写法是：
code复制cl main.c /I.\include /link /LIBPATH:.\lib myutils.lib
使用 Visual Studio 集成开发环境时，则要在“链接器 -> 输入 -> 附加依赖项”里加上 myutils.lib，并且在“链接器 -> 常规 -> 附加库目录”里填入 .lib 文件所在目录。
这里说一个很多新手会犯的错误：链接静态库时，库文件在命令中的位置不是随便放的。 在使用 GCC 时，被依赖的库要放在依赖它的一方之后。比如 main.o 调用了 libmyutils.a 中的函数，命令行写成 gcc main.o -lmyutils 是对的，但如果写成 gcc -lmyutils main.o，在某些老版本 GCC 中就会出现“链接成功但运行时报错”或者直接报“undefined reference”的情况。原因在于 GCC 的链接器是顺序扫描的，链接到 -lmyutils 时还没看到 main.o 中的未解析符号，自然不知道该从库里拉哪些目标文件。
3. 动态库的编译过程与创建实操
3.1 动态库解决的核心痛点
动态库的存在，本质上是为了解决静态库的几个先天性缺陷。第一是磁盘和内存浪费：如果 10 个程序都静态链接同一个库，那这个库的代码会被复制 10 份。动态库只保留一份副本，多个进程运行时可以在内存中共享同一份只读代码页。第二是更新成本：静态库更新后，所有依赖它的程序都必须重新编译链接；动态库更新后，只要保持接口兼容，程序无需重新编译就能用上新版本。
代价是什么？最直接的代价就是“DLL Hell”或者叫“依赖地狱”——主程序运行时要能找到动态库，如果找不到就拒绝启动，或者在运行到某个函数时崩溃。L