动态编译 vs. 静态编译，容器时代那个更有优势？

一、动态编译 vs. 静态编译：一场关于“依赖”的战争

要理解静态编译，我们首先要明白它的对立面——动态编译，这也是 C、C++ 以及 Java、Python、C#、Ruby 等大多数主流语言所采用的方式。

1. 动态编译：运行时“借”东西

想象一下你要写一篇论文，你需要引用很多书籍和资料。

• 你的代码：就是你自己写的论文正文。
• 标准库/第三方库：就是你要引用的那些书籍和资料（比如 C 语言的 printf 函数，或者 Python 的 requests 库）。

在动态编译模型下，编译器（比如 C 的 gcc）在编译你的程序时，并不会把那些“书籍”的全部内容都抄录到你的“论文”里。它只是在你的论文里做了一个标记：“这里引用了《XXX》第 Y 页的 Z 段落”。

• 链接过程：编译完成后，会生成一个可执行文件（比如 my_app）和一系列动态链接库（在 Linux 上是 .so 文件，Windows 上是 .dll 文件，macOS 上是 .dylib 文件）。这些 .so 文件就像一个公共图书馆。
• 运行时：当你运行 ./my_app 时，操作系统的动态链接器 会介入。它读取你程序里的那些“引用标记”，然后去系统的“公共图书馆”（比如 /usr/lib, /lib 目录）里找到对应的 .so 文件，把它们加载到内存中，让你的程序调用。

动态编译的优缺点：

• 优点：
      *   节省磁盘和内存空间：多个程序可以共享同一个库文件。比如，10 个程序都用到了 libc.so.6，内存里只需要加载一份这个库。
      *   便于更新：如果库发现了一个安全漏洞，只需要更新这个 .so 文件，所有依赖它的程序都不需要重新编译，就能用上修复后的库。
• 缺点：
      *   “依赖地狱” (Dependency Hell)：这是它最大的问题。你要运行程序，目标机器上必须安装了所有正确的库，并且版本要兼容。你经常会遇到 libxxx.so.1: cannot open shared object file: No such file or directory 或者 version 'GLIBC_2.29' not found 这样的错误。为了解决依赖，你需要用包管理器（apt, yum）安装，但这又可能引入新的依赖冲突。
      *   部署复杂：你不能只复制一个可执行文件就完事，你还需要确保目标环境的“图书馆”是齐全的。

2. 静态编译：自给自足的“孤岛”

现在，我们换一种写论文的方式。

在静态编译模型下，编译器在编译你的程序时，会把你用到的所有库函数的实际代码，像“抄书”一样，全部复制并嵌入到你最终生成的可执行文件中。