编译器视角下的 Python 调用 C++：从符号到内存的完整链路

1. 引言

import math_ext 这行代码背后发生了什么？

对于一个 Python 开发者来说，import 只是一行代码。但对于编译器和操作系统而言，这是一场跨越三个阶段——编译、链接、运行时——的精密协作。编译器留下占位符，链接器合并符号表，动态链接器在最后一刻填上真实地址。每一步都尽量少做事，把能推迟的决定推迟到最后。

本文将从编译器的视角，完整拆解 Python 调用 C++ 函数时发生的所有事情。我们不会停留在"写一个 pybind11 绑定"的层面，而是深入到 ELF 文件结构、符号表查找、GOT/PLT 延迟绑定等底层机制，理解两个不同编译模型的语言是如何在运行时互相理解对方的。

2. 问题本质：两个异构语言的互操作

Python 和 C++ 在几乎所有维度上都不同：

维度	Python	C++
编译模型	解释执行 + 字节码	AOT 编译到机器码
类型系统	动态类型，运行时检查	静态类型，编译期检查
内存管理	引用计数 + GC	手动 / RAII / 智能指针
函数调用	CPython 内部 C API	各平台 calling convention
二进制形式	.py 字节码 / .so 扩展	.so 共享库

两者能互操作的根本原因只有一个：C ABI 是所有语言都能理解的"普通话"。无论你用 pybind11、Cython 还是手写 ctypes，最终都会归结为同一条链路：

Python 对象 → C API wrapper（类型转换）→ C++ 函数 → 返回值转回 Python 对象

3. 最小化实现：暴露 C++ 函数给 Python

为了看清原理，我们不借助任何框架，直接用 Python C API 写一个最小化的绑定。

3.1 C++ 侧实现

// math_module.cpp
#include <Python.h>

// 纯 C++ 实现
static int64_t fibonacci(int n) {
    if (n <= 1) return n;
    int64_t a = 0, b = 1;
    for (int i = 2; i <= n; i++) {
        int64_t tmp = a + b;
        a = b;
        b = tmp;
    }
    return b;
}

// C wrapper —— binding 的核心：类型转换
static PyObject* py_fibonacci(PyObject* self, PyObject* args) {
    int n;
    // ① 解析 Python 参数 → C 类型
    if (!PyArg_ParseTuple(args, "i", &n))
        return NULL;
    if (n < 0) {
        PyErr_SetString(PyExc_ValueError, "n must be >= 0");
        return NULL;
    }

    // ② 调用真正的 C++ 函数
    int64_t result = fibonacci(n);

    // ③ C 类型 → Python 对象
    return PyLong_FromLongLong(result);
}

// 模块方法表
static PyMethodDef methods[] = {
    {"fibonacci", py_fibonacci, METH_VARARGS, "compute fibonacci(n)"},
    {NULL, NULL, 0, NULL}
};

// 模块定义
static struct PyModuleDef module = {
    PyModuleDef_HEAD_INIT, "math_ext", NULL, -1, methods
};

// 模块入口 —— Python import 时由动态链接器调用
PyMODINIT_FUNC PyInit_math_ext(void) {
    return PyModule_Create(&module);
}

这段代码暴露了三个核心机制：

PyArg_ParseTuple：格式字符串驱动的类型转换。"i" 表示期望一个 Python int，内部会做 PyLong_Check 类型检查和 PyLong_AsLong 值提取。
return NULL + PyErr_SetString：C++ 没有异常机制，错误通过"设置全局异常状态 + 返回空指针"传递给 CPython。
PyLong_FromLongLong：分配一个新的 PyLongObject，设置 ob_refcnt = 1（调用者持有引用），返回 PyObject*。

3.2 编译为共享库

g++ -O2 -shared -fPIC math_module.cpp \
    $(python3-config --includes --ldflags) \
    -o math_ext.cpython-312-x86_64-linux-gnu.so

关键编译选项：

-shared：生成共享库（ELF 类型 ET_DYN），而非可执行文件
-fPIC：生成位置无关代码（Position Independent Code），因为共享库的加载地址在运行时才确定
$(python3-config --includes)：引入 Python.h 头文件路径
输出文件名遵循 Python 的命名约定：{module}.cpython-{version}-{abi}.so

3.3 Python 侧调用

import math_ext

print(math_ext.fibonacci(50))  # 12586269025

就这三行。但 import 这一行背后，编译器和操作系统做了一系列精密的工作。下面逐层拆解。

4. 第一层：编译期——符号表与重定位

4.1 编译器的符号表

编译器在编译 math_module.cpp 时，维护一张内部符号表（本质上是一个 hash map）：

"fibonacci"    → { scope: local,    type: int64_t(int),     defined: true,  linkage: none }
"py_fibonacci" → { scope: global,   type: PyObject*(...),   defined: true,  linkage: external }
"PyArg_ParseTuple"  → { scope: global, type: ..., defined: false, linkage: external }
"PyLong_FromLongLong" → { scope: global, type: ..., defined: false, linkage: external }

编译期不关心函数在哪，只关心签名对不对。当遇到 PyArg_ParseTuple(args, "i", &n) 时，编译器：

查符号表确认 PyArg_ParseTuple 已声明（通过 Python.h 的头文件声明）
生成函数调用指令，但不知道目标地址
留下一个重定位条目（Relocation Entry）：“这里需要填一个地址，以后再说”

; 编译器生成的汇编（示意）
call PyArg_ParseTuple    ; → 重定位条目: R_X86_64_PLT32 PyArg_ParseTuple

这就是重定位的本质：编译器承认自己的无知，把填地址的工作推迟给链接器或动态链接器。

4.2 目标文件中的符号表

编译器产出 .o 文件后，可以用 readelf -s 查看其中的符号表：

Symbol table '.symtab':
  Num:    Value  Size  Type  Bind   Vis     Ndx  Name
    1: 00000000     0  NOTYPE LOCAL  DEFAULT UND
    2: 00000000     0  FUNC   GLOBAL DEFAULT UND   PyArg_ParseTuple
    3: 00000000     0  FUNC   GLOBAL DEFAULT UND   PyLong_FromLongLong
    5: 00000000    47  FUNC   GLOBAL DEFAULT    5  py_fibonacci
    6: 00000000    30  FUNC   GLOBAL DEFAULT    5  PyInit_math_ext

关键字段：

UND（Undefined）：这个编译单元引用了但没定义的符号，需要别人提供
带 Value 的条目：本编译单元定义的符号，Value 是在 .text 段中的偏移量
Bind=GLOBAL：外部可见，其他编译单元可以引用

5. 第二层：链接期——静态链接器

5.1 静态链接器做什么

静态链接器（ld）的工作是：

把所有 .o 文件合并成一个 .so
解析内部符号（所有 .o 合起来能找到的）
把外部符号标记为动态符号，留给运行时解析

对于我们的 math_ext.so，PyArg_ParseTuple 和 PyLong_FromLongLong 在编译阶段和链接阶段都找不到——它们来自 libpython3.12.so。链接器会将它们写入 .dynsym（动态符号表），并生成对应的重定位条目。

5.2 重定位类型

链接器处理的重定位类型决定了"以后怎么填地址"：

重定位类型	含义	典型场景
`R_X86_64_PLT32`	PC 相对偏移调用	编译器生成的 `call` 指令
`R_X86_64_GLOB_DAT`	GOT 绝对地址，加载时绑定	全局变量访问
`R_X86_64_JUMP_SLOT`	GOT 条目，延迟绑定	跨库函数调用
`R_X86_64_RELA`	绝对地址引用	代码中的常量地址

JUMP_SLOT 是最关键的类型——它告诉动态链接器：“这个地址先用一个桩值，等函数真正被调用时再填”。

6. 第三层：运行时——动态链接器

这是 import math_ext 时真正发生的事情。动态链接器（ld-linux-x86-64.so）接管，完成最后的符号解析和地址填充。

6.1 ELF 文件的完整布局

在深入运行时之前，先看清楚 .so 文件的结构：

┌─────────────────────────────────────────┐
│           ELF Header (64 bytes)          │
│  e_type=ET_DYN, e_machine=EM_X86_64    │
│  e_phoff → Program Headers              │
│  e_shoff → Section Headers              │
├─────────────────────────────────────────┤
│         Program Headers (PT_*)           │  ← 操作系统加载时看这个
│  PT_LOAD: .text 段 → 虚拟地址 0x...    │
│  PT_DYNAMIC: .dynamic 段 → 偏移 0x...   │
│  PT_INTERP: "/lib64/ld-linux.so"        │
├─────────────────────────────────────────┤
│                                         │
│  .interp      "/lib64/ld-linux.so"      │
│  .gnu.hash    符号哈希表                │
│  .dynsym      动态符号表                │
│  .dynstr      符号名字符串表            │
│  .text        机器码                    │
│  .rodata      只读数据                  │
│  .got.plt     全局偏移表                │
│  .plt         PLT 桩代码                │
│  .dynamic     动态链接元数据            │
│  .rela.plt    延迟重定位表              │
│                                         │
├─────────────────────────────────────────┤
│         Section Headers                  │  ← readelf/链接器看这个
└─────────────────────────────────────────┘

一个容易混淆的点：Program Headers 和 Section Headers 描述的是同一块内存的不同视图。操作系统加载时只看 Program Headers（它不知道 .text 这个名字），而工具分析时看 Section Headers。

6.2 dlopen 的完整流程

Python: import math_ext
  │
  ▼
dlopen("math_ext.cpython-312-x86_64-linux-gnu.so")
  │
  ├─ 1. mmap 文件到内存
  │     读 ELF Header → 找到 Program Headers
  │     对每个 PT_LOAD 段：mmap 到虚拟地址空间
  │     操作系统只关心：从哪加载、映射到哪个虚拟地址、权限是什么
  │
  ├─ 2. 读 .dynamic 段
  │     DT_NEEDED → "libpython3.12.so" → 已加载，跳过
  │     DT_NEEDED → "libc.so.6"        → 已加载，跳过
  │     DT_HASH   → .gnu.hash 地址
  │     DT_SYMTAB → .dynsym 地址
  │     DT_STRTAB → .dynstr 地址
  │     DT_JMPREL → .rela.plt 地址
  │
  ├─ 3. 立即重定位（.rela.dyn）
  │     填充 .got 中需要加载时就确定的地址
  │
  ├─ 4. 调用 .init 段
  │     C++ 全局构造函数、__attribute__((constructor)) 在这里执行
  │
  └─ 5. 查找入口符号 "PyInit_math_ext"
        用 .gnu.hash 在 .dynsym 中查找
        找到 → 返回函数指针给 CPython
        │
        ▼
      CPython 调用 PyInit_math_ext()
        → 注册模块方法表
        → math_ext.fibonacci 可用

6.3 .gnu.hash：O(1) 符号查找

如果遍历整个 .dynsym 来找符号，复杂度是 O(n)。对于有上千符号的 libpython3.12.so，这太慢了。GNU hash table 将查找优化到 O(1)。

其结构如下：

.gnu.hash:
┌──────────────┐
│ nbuckets     │  哈希桶数量
│ symoffset    │  第一个动态符号的索引
│ bloom_size   │  Bloom filter 大小
│ bloom_shift  │  Bloom filter 移位量
├──────────────┤
│ bloom[0..N]  │  Bloom filter —— 快速排除"肯定不存在"
├──────────────┤
│ buckets[0..N]│  哈希桶 → chain 表的起始索引
├──────────────┤
│ chains[...]  │  链表，每个条目 = 符号索引 + hash 低 31 位
└──────────────┘

查找 “PyArg_ParseTuple” 的过程：

1. 计算 hash = gnu_hash("PyArg_ParseTuple") = 0x3A7F...

2. Bloom filter 快速排除（最精妙的部分）：
   bloom[hash % bloom_size] 的第 (hash >> bloom_shift) % 64 位
   ├─ 没置位 → 符号肯定不存在，直接返回
   └─ 置位了 → 可能存在，继续

3. 定位 bucket：
   index = buckets[hash % nbuckets]
   如果 index == 0 → 空桶，不存在

4. 遍历 chain：
   for each chain[index]:
     if (chain[index] & ~1) == (hash & ~1):  // hash 低 31 位匹配
       if .dynstr[sym[index].st_name] == "PyArg_ParseTuple":
         return sym[index]  // 找到！

Bloom filter 的价值在于：大部分查找在第一步就被过滤掉了，不需要遍历 chain。这是"大概率不存在"场景下的最优策略——而符号查找恰好符合这个特征（大部分库名都不匹配）。

6.4 .dynsym + .dynstr：符号表和字符串表

.dynsym 中的每个条目（24 字节）：

typedef struct {
    uint32_t st_name;    // 在 .dynstr 中的偏移 → 指向 "PyArg_ParseTuple\0"
    uint8_t  st_info;    // 绑定类型（GLOBAL/WEAK）+ 符号类型（FUNC/OBJECT）
    uint8_t  st_other;
    uint16_t st_shndx;   // 在哪个 section（UND = 未定义）
    uint64_t st_value;   // 定义后的虚拟地址
    uint64_t st_size;    // 大小（函数的字节数）
} Elf64_Sym;

字符串单独存在 .dynstr 中，符号表只存偏移量。这样相同的字符串（比如多个符号引用同一个库）不会重复存储。

6.5 GOT/PLT：延迟绑定的核心

这是整个调用链中最精妙的设计。目标：第一次调用时解析地址，之后直接使用缓存的结果。

PLT（Procedure Linkage Table）—— 桩代码

.plt[0]:
    push    GOT[1]          ; 压入 link_map（告诉解析器在哪个库里找）
    jmp     GOT[2]          ; 跳到 ld-linux.so 的 _dl_runtime_resolve
    nop

.plt[1]:  ; PyArg_ParseTuple 的 PLT 桩
    jmp     GOT[PyArg_ParseTuple]   ; 第一次跳到自己下面的 push
    push    0                        ; 重定位索引 = 0
    jmp     .plt[0]                  ; 触发解析
    nop

.plt[2]:  ; PyLong_FromLongLong 的 PLT 桩
    jmp     GOT[PyLong_FromLongLong]
    push    1                        ; 重定位索引 = 1
    jmp     .plt[0]
    nop

GOT（Global Offset Table）—— 地址缓存

GOT[0]: 0x7f..._DYNAMIC    ; 指向 .dynamic 段
GOT[1]: 0x7f..._link_map   ; 链接器的数据结构
GOT[2]: 0x7f..._dl_resolve ; ld-linux.so 的解析入口
GOT[3]: .plt[1] + 6        ; PyArg_ParseTuple ← 初始指向自己的 push 指令！
GOT[4]: .plt[2] + 6        ; PyLong_FromLongLong ← 同上

注意 GOT[3] 的初始值：它不是函数的真实地址，而是指向 .plt[1] 中 push 0 那条指令。这是一个自引用的"跳板"。

第一次调用

py_fibonacci 中的 call PyArg_ParseTuple
  │
  ▼
jmp GOT[3]  → 跳到 .plt[1] + 6（push 0 指令）
  │
  ▼
push 0           ; 重定位表索引
  │
  ▼
jmp .plt[0]      ; 进入解析器
  │
  ▼
push link_map    ; 告诉解析器在哪个库的符号表中搜索
jmp _dl_runtime_resolve
  │
  ▼
ld-linux.so:
  1. 用索引 0 查 .rela.plt → 找到符号名 "PyArg_ParseTuple"
  2. 在所有已加载库的 .dynsym 中搜索
  3. 在 libpython3.12.so 中找到定义 → 0x7f3a4c000010
  4. 把 0x7f3a4c000010 写入 GOT[3]  ← 关键：修改 GOT！
  5. 跳转到 0x7f3a4c000010 执行

第二次调用

py_fibonacci 中的 call PyArg_ParseTuple
  │
  ▼
jmp GOT[3]  → 这次 GOT[3] = 0x7f3a4c000010（真实地址）
  │
  ▼
直接执行 PyArg_ParseTuple，零额外开销

这就是**延迟绑定（Lazy Binding）**的精髓：把最昂贵的符号解析推迟到函数真正被调用的那一刻，之后永远不再重复。

6.6 .dynamic：动态链接的元数据

.dynamic 段是动态链接器的"配置文件"：

tag                值
─────────────────  ────────────────────────
DT_NEEDED         "libpython3.12.so.1.0"   ; 依赖的共享库
DT_NEEDED         "libc.so.6"              ; 依赖的共享库
DT_NEEDED         "libstdc++.so.6"         ; 依赖的共享库
DT_HASH           0x400                    ; .gnu.hash 的地址
DT_STRTAB         0x600                    ; .dynstr 的地址
DT_SYMTAB         0x500                    ; .dynsym 的地址
DT_PLTGOT         0x800                    ; .got.plt 的地址
DT_PLTRELSZ       48                       ; .rela.plt 的大小
DT_JMPREL         0xA00                    ; .rela.plt 的地址
DT_INIT           0x1100                   ; .init 段地址
DT_FINI           0x1150                   ; .fini 段地址
DT_NULL           0                        ; 结束标记

动态链接器 dlopen 时第一步就是读这个段。没有它，链接器不知道符号表在哪、GOT 在哪、需要加载哪些依赖。

6.7 .rela.plt：重定位信息

每个延迟绑定的符号都有一个重定位条目：

typedef struct {
    uint64_t r_offset;   // GOT 中的地址（要修改的位置）
    uint64_t r_info;     // 高 32 位 = 符号表索引，低 32 位 = 重定位类型
    int64_t  r_addend;   // 加数（JUMP_SLOT 通常为 0）
} Elf64_Rela;

.rela.plt:
  [0] offset=GOT[3],  sym_idx=1, type=R_X86_64_JUMP_SLOT  // PyArg_ParseTuple
  [1] offset=GOT[4],  sym_idx=3, type=R_X86_64_JUMP_SLOT  // PyLong_FromLongLong

_dl_runtime_resolve 正是通过这个表把符号名和 GOT 位置对应起来的。

7. 完整调用链：一次 import 的全生命周期

把所有东西串起来，一次 import math_ext 的完整生命周期：

Python 解释器: import math_ext
  │
  ▼
CPython 调用内置 import 机制
  │ 查找 sys.path → 找到 math_ext.cpython-312-x86_64-linux-gnu.so
  │
  ▼
dlopen("math_ext.cpython-312-x86_64-linux-gnu.so")
  │
  ├─ mmap .so 文件到进程地址空间
  │  └─ 操作系统只看 Program Headers，不知道 .text、.got 这些名字
  │
  ├─ 读 .dynamic → DT_NEEDED: libpython3.12.so
  │  └─ 已在进程的已加载库列表中，跳过
  │
  ├─ 执行立即重定位（.rela.dyn）
  │  └─ 填充 .got 中的绝对地址
  │
  ├─ 调用 .init 段
  │  └─ C++ 全局构造函数在这里执行
  │
  └─ dlsym(handle, "PyInit_math_ext")
     │
     ├─ .gnu.hash 查找
     │  ├─ Bloom filter: bloom[idx] bit OK → 可能存在
     │  ├─ bucket: 找到 chain 起始位置
     │  └─ chain 遍历: 匹配 "PyInit_math_ext" → 找到！
     │
     ▼
  返回 PyInit_math_ext 的函数指针
     │
     ▼
CPython 调用 PyInit_math_ext()
  └─ PyModule_Create(&module) → 注册方法表
  └─ math_ext.fibonacci 可用

────── 后续每次调用 fibonacci(n) ──────

Python: math_ext.fibonacci(50)
  │
  ▼
CPython: 查找方法表 → 找到 py_fibonacci
  │
  ▼
py_fibonacci(self, (50,))
  │
  ├─ PyArg_ParseTuple((50,), "i", &n)
  │  └─ 类型检查 + 值提取 → n = 50
  │  └─ 第一次调用走 PLT → _dl_runtime_resolve → 填 GOT → 执行
  │  └─ 之后直接 jmp GOT → 零开销
  │
  ├─ fibonacci(50)
  │  └─ 纯 C++ 执行，与 Python 完全无关
  │  └─ result = 12586269025
  │
  └─ PyLong_FromLongLong(12586269025)
     └─ 分配 PyLongObject, refcnt = 1
     └─ 返回 PyObject* 给 CPython
     └─ CPython 绑定到 Python 变量，refcnt 由 GC 管理

8. 类型系统：PyObject —— 万物皆指针

理解了调用链，再看类型转换层。Python 在 C 层面的万能类型是 PyObject*：

// CPython 对象头（简化）
typedef struct _object {
    Py_ssize_t ob_refcnt;   // 引用计数
    PyTypeObject *ob_type;  // 类型指针（也是 PyObject*）
} PyObject;

所有 Python 对象（int、str、list、dict、自定义类……）都以这个结构开头。类型转换就是在这层"万能接口"和 C++ 的强类型之间做翻译：

Python int   ←→ PyLongObject  ←→ int64_t
Python str   ←→ PyUnicodeObject ←→ const char* / std::string
Python list  ←→ PyListObject  ←→ std::vector<T>
Python dict  ←→ PyDictObject  ←→ std::map<K,V>
Python 自定义对象 ←→ PyObject* ←→ C++ class instance

异常传递更特殊——C++ 没有 Python 的异常机制，错误通过全局状态传递：

正常路径: return PyLong_FromLongLong(result)   → 返回非 NULL 的 PyObject*
错误路径: PyErr_SetString(PyExc_ValueError, "msg"); return NULL

CPython 在每次调用 C 扩展函数后检查返回值是否为 NULL，如果是就检查全局异常状态。

9. 内存管理：引用计数的双向同步

当绑定涉及 C++ 对象（而非基本类型）时，内存管理变得复杂。pybind11 的做法是给每个 C++ 对象包一层 Python holder：

Python 层:  PyObject (refcnt 由 CPython 管理)
               │
               ▼
Holder 层:  std::shared_ptr<MyClass> (refcnt 由 C++ 管理)
               │
               ▼
C++ 层:     MyClass 实例 (真正的数据)

当 Python 引用计数归零时:
  → 触发 tp_dealloc
  → 释放 shared_ptr
  → shared_ptr refcnt -1
  → 如果也归零，delete MyClass

两个引用计数系统需要同步——这是所有 binding 框架（pybind11、Cython、SWIG）最复杂的部分，也是手写绑定时最容易出 bug 的地方。

10. 设计哲学：分层延迟

回顾整个体系，一个贯穿始终的设计原则是分层延迟——每一层都尽量少做事：

阶段	能确定什么	推迟什么
编译器	类型检查、代码生成	函数地址（留重定位占位符）
静态链接器	合并段、解析内部符号	外部符号地址（标记为动态）
动态链接器	mmap、立即重定位	PLT 符号（等第一次调用）
第一次调用	解析符号、填入 GOT	无（之后直接走缓存）

这不是偷懒，而是工程上的最优策略。越晚做的决定，可用的信息就越多。编译器不知道运行时地址，但第一次调用时，所有库都已加载，地址空间已经确定——这时候解析反而最简单。

11. 总结

Python 调用 C++ 的底层机制可以归纳为几个核心概念：

C ABI 是桥梁：所有跨语言调用最终都通过 C 调用约定完成，extern "C" 保证符号名不被 mangle
重定位是延迟填坑：编译器留占位符，链接器部分填充，动态链接器最终填充
GOT/PLT 是缓存层：第一次调用解析地址并缓存，之后零开销
PyObject 是万能接口：所有 Python 对象在 C 层面都是 PyObject*，类型转换在这个边界发生
引用计数是生命线：Python 和 C++ 的内存管理需要双向同步，这是 binding 框架最核心的工程问题
.gnu.hash 是加速器：Bloom filter + hash chain 实现 O(1) 符号查找

理解了这些机制，你就能理解为什么 pybind11 能让绑定"看起来像魔法"——它只是把所有这些底层细节都封装起来了。而当你遇到诡异的段错误、符号未定义、或者引用计数泄漏时，知道底层发生了什么，才能精准定位问题。

本文基于 x86-64 Linux 环境讨论。ELF 格式和动态链接机制在不同平台（macOS 的 Mach-O、Windows 的 PE/COFF）上原理相同但结构不同。

编译器视角下的 Python 调用 C++：从符号到内存的完整链路#

1. 引言#

2. 问题本质：两个异构语言的互操作#

3. 最小化实现：暴露 C++ 函数给 Python#

3.1 C++ 侧实现#

3.2 编译为共享库#

3.3 Python 侧调用#

4. 第一层：编译期——符号表与重定位#

4.1 编译器的符号表#

4.2 目标文件中的符号表#

5. 第二层：链接期——静态链接器#

5.1 静态链接器做什么#

5.2 重定位类型#

6. 第三层：运行时——动态链接器#

6.1 ELF 文件的完整布局#

6.2 dlopen 的完整流程#

6.3 .gnu.hash：O(1) 符号查找#

6.4 .dynsym + .dynstr：符号表和字符串表#

6.5 GOT/PLT：延迟绑定的核心#

PLT（Procedure Linkage Table）—— 桩代码#

GOT（Global Offset Table）—— 地址缓存#

第一次调用#

第二次调用#

6.6 .dynamic：动态链接的元数据#

6.7 .rela.plt：重定位信息#

7. 完整调用链：一次 import 的全生命周期#

8. 类型系统：PyObject —— 万物皆指针#

9. 内存管理：引用计数的双向同步#

10. 设计哲学：分层延迟#

11. 总结#