你有一个正在运行的 Python 进程——也许是一个生产环境中的 Web 服务，也许是一个跑了三小时的数据管道。它变慢了，或者出了某种诡异的 bug。你不能停掉它、不能重启它、不能加 print 语句。

怎么办？

答案是进程注入（process injection）：在不重启目标进程的前提下，将诊断代码注入到一个正在运行的 Python 解释器中。这正是 peeka、memray、pyrasite 等工具的核心能力。

本文将从底层原理到工程实践，系统地拆解 Python 进程注入的三代技术方案。

1. 进程注入的本质问题

要理解进程注入，先要理解我们面临的约束：

• 地址空间隔离：每个进程有独立的虚拟地址空间，A 进程无法直接读写 B 进程的内存
• GIL（全局解释器锁）：Python 的 C API 调用几乎都需要持有 GIL
• 执行时机：目标进程可能正处于任何状态——malloc 中途、GC 扫描中、持有 import 锁……

所以，进程注入需要回答三个问题：

1. 如何进入目标进程的地址空间？（跨进程控制）
2. 如何安全地执行 Python 代码？（GIL 获取）
3. 何时执行才不会崩溃？（时机选择）

不同的工具对这三个问题给出了不同的答案。

2. 第一代：pyrasite 与 GDB 直接调用 C API

pyrasite（2011 年）是最早的 Python 进程注入工具之一。它的方案简单直接：

原理

利用 ptrace 系统调用暂停目标进程，然后通过 GDB 直接调用 Python 的 C API 执行任意 Python 代码。

核心代码

pyrasite 的注入逻辑只有几行：

# pyrasite/injector.py（简化）
gdb_cmds = [
    'call (int) PyGILState_Ensure()',
    'call (int) PyRun_SimpleString("exec(open(\\'%s\\').read())")' % filename,
    'call (void) PyGILState_Release($1)',
]
subprocess.Popen(
    'gdb -p %d -batch %s' % (pid, ' '.join(
        ["-eval-command='call %s'" % cmd for cmd in gdb_cmds]
    )),
    shell=True
)

即：

1. GDB 通过 ptrace(PTRACE_ATTACH) 暂停目标进程
2. 在暂停点直接调用 PyGILState_Ensure() 获取 GIL
3. 调用 PyRun_SimpleString() 执行一段 Python 代码
4. 调用 PyGILState_Release() 释放 GIL
5. GDB detach，目标进程恢复执行

ptrace 是什么？

ptrace 是 Linux 内核提供的进程调试接口。GDB、strace、lldb 的底层都依赖它。

调试器进程                    目标进程
    │                           │
    │── ptrace(ATTACH, pid) ───>│  暂停目标
    │                           │  (SIGSTOP)
    │── ptrace(PEEKTEXT) ──────>│  读内存
    │── ptrace(POKETEXT) ──────>│  写内存
    │── ptrace(GETREGS) ───────>│  读寄存器
    │── ptrace(SETREGS) ───────>│  改寄存器 -> 修改执行流
    │── ptrace(CONT) ──────────>│  恢复执行
    │── ptrace(DETACH) ────────>│  脱离

GDB 正是利用 ptrace 的能力，在目标进程的上下文中"调用"C 函数。具体来说，GDB 每执行一条 call 命令，都会经历以下 6 步：

1. 保存目标进程当前的寄存器状态
2. 将函数参数写入寄存器/栈（遵循 ABI 调用约定）
3. 将指令指针（rip）设为目标函数地址
4. 设置断点用于在函数返回后接管控制
5. 恢复执行
6. 函数执行完毕后，GDB 命中断点，恢复原始寄存器

也就是说，pyrasite 的三条 GDB 命令（call PyGILState_Ensure()、call PyRun_SimpleString(...)、call PyGILState_Release($1)）各自独立地经历这 6 步，而非 6 步整体对应 3 个函数。每次 call 都是一次完整的"保存->篡改->执行->恢复"循环。

为什么这个方案危险？

问题出在时机上。当 GDB attach 并暂停目标进程时，目标可能正处于任何状态：

目标进程的执行时间线：
... -> malloc() -> [GDB 在这里暂停] -> PyGILState_Ensure() -> 💥

问题：malloc 内部持有 heap lock
      PyRun_SimpleString 可能也要调 malloc
      -> 死锁

更具体地说：

pyrasite 本质上是在"碰运气"——大多数时候目标进程不在这些危险状态，所以注入成功。但在生产环境中，这种不确定性是不可接受的。

3. 第二代：memray/peeka 的 dlopen + pthread 方案

memray（Bloomberg 开源的内存分析器）和 peeka 在 Python 3.8-3.13 上采用了相似的改进方案。核心思路是：不在 ptrace 暂停点直接执行 Python 代码，而是注入一个 C 扩展，由 C 扩展在安全的时机执行代码。

原理概览

调试器(GDB/LLDB)                目标进程
    │                              │
    │── ptrace ATTACH ────────────>│  暂停
    │── 等待安全断点命中 ────────────>│  malloc/PyMem_* 返回后
    │                              │
    │── dlopen("_inject.so") ─────>│  加载 C 扩展到目标地址空间
    │── call peeka_spawn_agent() ─>│  创建新 pthread
    │── ptrace DETACH ────────────>│  恢复执行
    │                              │
    │                              │  [新 pthread]
    │                              │  ├─ connect() 回连调试器
    │                              │  ├─ recv() 接收 agent 脚本
    │                              │  ├─ PyGILState_Ensure() ← 等待安全时机
    │                              │  ├─ PyEval_EvalCode() 执行 agent
    │                              │  └─ PyGILState_Release()

关键改进有三点：安全断点、dlopen 注入、独立线程。

3.1 安全断点——选择正确的时机

pyrasite 在任意位置暂停后就执行 C API，而 memray/peeka 等到安全位置才注入。

以 peeka 的 GDB 脚本为例：

# peeka/core/_attach.gdb
b malloc
b calloc
b realloc
b free
b PyMem_Malloc
b PyMem_Calloc
b PyMem_Realloc
b PyMem_Free
b PyErr_CheckSignals
b PyCallable_Check

commands 1-10
    disable breakpoints
    delete breakpoints
    call (void*)dlopen($peeka_injector, $peeka_rtld_now)
    call (int)peeka_spawn_agent($peeka_port)
end

continue

解读：

1. 在 malloc、PyMem_Malloc 等函数的入口设置断点
2. 调用 Py_AddPendingCall(&PyCallable_Check, 0) 安排一个 pending call（确保 CPython 的 eval loop 会调用 PyCallable_Check，从而命中我们的断点）
3. 恢复执行（continue），等待目标进程自然地调用这些函数
4. 断点命中时，我们知道当前位置是函数入口——没有持有 heap lock、没有处于 GC 中途
5. 此时再执行 dlopen 和 spawn

这比 pyrasite 安全得多：我们不是在任意位置注入，而是在一个已知的安全点。

Py_AddPendingCall 的作用：如果目标进程处于纯 Python 代码的 tight loop 中（不调用任何 C 函数），我们的 malloc/PyMem 断点可能永远不会命中。Py_AddPendingCall 注册的回调会在 Python eval loop 的下一个"检查点"被调用，确保断点一定会触发。

3.2 dlopen——将 C 扩展加载到目标进程

dlopen 是 POSIX 系统的动态链接器接口。通过 GDB 在目标进程中调用 dlopen("_inject.abi3.so", RTLD_NOW)，我们将一个编译好的 C 扩展加载到目标进程的地址空间中。

这比 PyRun_SimpleString 强大的关键在于：C 代码可以创建线程，可以操作底层系统资源，不受 GIL 约束。

peeka 在 macOS 上使用 LLDB 完成相同的工作：

# peeka/core/_attach.lldb
expr auto $dlsym = (void* (*)(void*, const char*))&::dlsym
expr auto $dlopen = $dlsym($rtld_default, "dlopen")
expr auto $dll = ((void*(*)(const char*, int))$dlopen)($libpath, $rtld_now)
expr auto $spawn = $dlsym($dll, "peeka_spawn_agent")
p ((int(*)(int))$spawn)($port) ? "FAILURE" : "SUCCESS"

3.3 独立线程——解耦注入与执行

dlopen 之后，GDB 调用 C 扩展的 peeka_spawn_agent() 函数。这个函数做了什么？

// peeka/core/_inject.c（核心逻辑）
__attribute__((visibility("default")))
int peeka_spawn_agent(int port)
{
    pthread_t thread;
    return pthread_create(&thread, NULL, &thread_body, (void*)(uintptr_t)port);
}

它不执行任何 Python 代码。它只是创建一个 pthread，然后立即返回。这样 GDB 可以快速 detach，目标进程恢复正常执行。

真正的工作在新线程中完成：

// 新线程的执行流程
static void run_client(uint16_t port)
{
    // 1. 通过 TCP 回连调试器，接收 agent 脚本
    int sock = connect_client(port);
    recvall(sock, &script, &script_len);

    // 2. 安全地执行 Python 代码
    run_script(script, &errmsg);
}

static int run_script(const char* script, char** errmsg)
{
    // 检查 Python 是否已初始化
    if (!Py_IsInitialized()) {
        *errmsg = copy_string("Python is not initialized");
        return 0;
    }

    // 获取 GIL —— 这里会等待，直到安全
    PyGILState_STATE gstate = PyGILState_Ensure();

    // 编译并执行 agent 脚本
    int ret = run_script_impl(script, errmsg);

    PyGILState_Release(gstate);
    return ret;
}

static int run_script_impl(const char* script, char** errmsg)
{
    // 构建干净的 globals 字典
    PyObject* builtins = PyImport_ImportModule("builtins");
    PyObject* globals = PyDict_New();
    PyDict_SetItemString(globals, "__builtins__", builtins);

    // 编译 + 执行
    PyObject* code = Py_CompileString(script,
                                       "_peeka_attach_hook.py",
                                       Py_file_input);
    PyObject* mod = PyEval_EvalCode(code, globals, globals);
    // ...
}

为什么独立线程更安全？

在 pyrasite 方案中，PyGILState_Ensure() 在 GDB 暂停目标进程时被调用——如果暂停的线程恰好持有 GIL，这里会死锁。

在 dlopen + pthread 方案中：

1. GDB 执行 dlopen -> spawn -> 立刻返回 -> GDB detach -> 目标进程恢复
2. 新线程调用 PyGILState_Ensure() 时，目标进程已经在正常运行
3. PyGILState_Ensure() 会等待 GIL 可用，而不是在暂停状态下强行获取

这消除了 GIL 死锁的主要原因。

3.4 反向连接——agent 代码的传输

一个有趣的设计细节是 agent 代码的传输。peeka 不是把代码内容写入 GDB 命令（字符串转义会很痛苦），而是采用反向连接：

[1] 调试器启动一个 TCP 服务，等待连接
[2] GDB 将端口号传给 peeka_spawn_agent(port)
[3] C 扩展中的新线程连接这个端口
[4] 调试器将 agent.py 的完整内容通过 TCP 发送过去
[5] C 扩展接收、编译、执行

这样做的好处是：agent 代码可以任意长、包含任意字符，不受 GDB 命令行的转义限制。

3.5 Legacy 回退——没有 C 扩展时怎么办？

如果 C 扩展不可用（比如没有编译、或者 GLIBC 版本不兼容），peeka 会回退到类似 pyrasite 的方式，但做了改进：

# peeka/core/attach.py — _inject_via_gdb_legacy()
bootstrap = f'_c = open("{agent_script}").read(); exec(_c);'

gdb_commands = [
    'call (int) PyGILState_Ensure()',
    f'call (int) PyRun_SimpleString("{bootstrap}")',
    'call (void) PyGILState_Release($1)',
]

通过 exec() 执行文件内容而非直接内联代码，减少了转义问题。但本质上仍然有 pyrasite 的时机安全隐患，只是作为最后的回退方案存在。

4. 第三代：PEP 768 与 sys.remote_exec

Python 3.14 引入了 PEP 768，从解释器层面提供了原生的进程注入支持。这是一个根本性的范式转变。

核心思想

前两代方案都是从外部强行进入目标进程（通过 ptrace/GDB/LLDB），然后在一个"可能安全"的位置执行代码。PEP 768 的思路则是：告诉解释器你要执行什么，让解释器自己在安全的时候执行。

运作机制

外部进程                       目标 Python 解释器
    │                              │
    │  (1) 读 /proc/pid/maps       │
    │      定位 PyRuntime 地址       │
    │                              │
    │  (2) 读 _Py_DebugOffsets      │
    │      获取内部结构偏移量         │
    │                              │
    │  (3) 写入脚本路径到            │
    │      tstate->debugger_        │
    │        script_path            │
    │                              │
    │  (4) 设置 pending call 标志   │
    │      tstate->debugger_        │
    │        pending_call = 1       │
    │                              │
    │  (5) 设置 eval breaker        │
    │      eval_breaker |=          │
    │        PLEASE_STOP_BIT        │
    │                              │
    │  完成，无需等待                │
    │                              │
    │                              │  ... 正常执行字节码 ...
    │                              │
    │                              │  eval loop 检查 eval_breaker
    │                              │  ↓
    │                              │  发现 pending_call 标志
    │                              │  ↓
    │                              │  _PyRunRemoteDebugger()
    │                              │  ↓
    │                              │  读取 script_path
    │                              │  ↓
    │                              │  fopen + PyRun_AnyFile
    │                              │  ↓
    │                              │  执行脚本 ✅

CPython 内部的关键代码：

// Python/ceval_gil.c
int _PyRunRemoteDebugger(PyThreadState *tstate)
{
    if (config->remote_debug == 1
        && tstate->remote_debugger_support.debugger_pending_call == 1)
    {
        tstate->remote_debugger_support.debugger_pending_call = 0;

        // 复制脚本路径（避免 race condition）
        char script_path[pathsz];
        memcpy(script_path,
               tstate->remote_debugger_support.debugger_script_path,
               pathsz);

        // 审计事件（可被安全策略拦截）
        PySys_Audit("cpython.remote_debugger_script", "s", script_path);

        // 执行脚本
        FILE* f = fopen(script_path, "r");
        PyRun_AnyFile(f, script_path);
        fclose(f);
    }
}

每个 PyThreadState 中的数据结构

// Include/cpython/pystate.h
#define _Py_MAX_SCRIPT_PATH_SIZE 512

typedef struct {
    int32_t debugger_pending_call;
    char debugger_script_path[_Py_MAX_SCRIPT_PATH_SIZE];
} _PyRemoteDebuggerSupport;

每个线程状态增加约 516 字节，但运行时开销几乎为零——只是 eval loop 中一次分支预测极大概率命中的 if 检查。

使用方式

peeka 的实现非常简洁：

# peeka/core/attach.py
def _attach_pep768(self) -> bool:
    agent_code = _read_agent_code()
    self.agent_script = self._create_agent_script(agent_code)

    # 一行搞定
    sys.remote_exec(self.pid, self.agent_script)

    # 等待 agent 就绪
    self._wait_for_agent_ready(timeout=self.READY_TIMEOUT_PEP768)
    return True

不需要 GDB、不需要 ptrace、不需要 C 扩展、不需要 dlopen。只需要调用者和目标进程是同一用户（或拥有 CAP_SYS_PTRACE），并且目标进程没有禁用远程调试。

安全保障

PEP 768 在安全性上的设计非常审慎：

1. 仅接受文件路径：sys.remote_exec 写入的是一个文件路径，不是代码内容。这意味着攻击者不仅需要跨进程写内存的权限，还需要在目标进程可读的文件系统路径上放置恶意脚本
2. 审计钩子：执行前触发 cpython.remote_debugger_script 审计事件，安全策略可以拦截
3. 可禁用：PYTHON_DISABLE_REMOTE_DEBUG 环境变量或 -X disable-remote-debug 启动参数
4. 编译时可移除：./configure --without-remote-debug

为什么 PEP 768 是本质性的进步？

PEP 768 实现中的已知问题与 CPython 修复

PEP 768 在 Python 3.14.0a5 合入后（gh-131937），社区在实际使用中发现了一系列实现缺陷。以下按严重程度梳理关键问题及其修复方案。

命名空间污染（gh-132859）

问题：注入脚本在 __main__ 模块的命名空间中执行，会意外覆盖目标进程的变量：

# 目标进程
x = 1
while x == 1:
    pass

# 注入脚本设置了 x = 42 -> 目标进程意外退出

修复：PR #132860（3.14.0a5）——脚本现在在隔离的命名空间中执行。如需访问主模块，需显式 import __main__。

非 UTF-8 路径编码失败（gh-133886）

问题：sys.remote_exec() 硬编码使用 UTF-8 编码脚本路径，导致在非 UTF-8 locale 环境下无法处理非 ASCII 路径，os.access() 找不到文件。

修复：PR #133887（3.14.0b1）——改用文件系统编码（sys.getfilesystemencoding()）代替硬编码 UTF-8。

无效参数导致段错误（gh-134064）

问题：sys.remote_exec(0, None) 在 ASAN/debug 构建中触发段错误——缺少 NULL 检查就直接解引用 script_path。由 fusil fuzzer 发现。

修复：PR #134067（3.14.0b1）——添加参数校验。

ELF 搜索中的异常状态污染（gh-137293）

问题：在 Linux 上搜索 /proc/pid/maps 定位 PyRuntime 时，search_linux_map_for_section() 对每个无法打开的文件（如已删除的 .so）都会设置异常。当最终在其他文件中找到 PyRuntime 时，函数返回成功但异常仍被设置：

# sys.remote_exec() 返回成功，但附带一个未清除的异常：
# OSError: Cannot open ELF file '/path/to/lib.so (deleted)'
# -> SystemError: returned a result with an exception set

修复：PR #137309——在搜索循环中继续搜索前清除异常。

ctypes 导致的重复 libpython 映射（gh-144563）

问题：当目标进程导入了 _ctypes 或 polars（底层使用 ctypes）时，/proc/pid/maps 中会出现多个 libpython 映射。远程调试代码无法处理重复项，导致 "Can't determine Python version" 或 "Failed to read debug offsets" 错误。

修复：PR #144595（3.15.0a6）——优雅处理重复映射，使用第一个有效的 PyRuntime。

远程调试偏移表缺乏校验（gh-148178）

问题：_remote_debugging 模块从目标进程内存读取 async_debug_offsets 后直接使用，未校验结构有效性。asyncio_task_object.size 字段被用作读取长度写入固定 4096 字节的栈缓冲区（SIZEOF_TASK_OBJ），恶意/被攻陷的目标进程可以构造更大的 size 导致栈缓冲区溢出。

修复：PR #148187——新增 validate_async_debug_offsets() 和 validate_debug_offsets() 对所有偏移表做边界校验（+511 行校验基础设施）。已回移至 3.14 分支（PR #148577）。

远程内存数据损坏导致崩溃（gh-140739）

问题：在 free-threading 构建中使用 --mode=gil 做性能采样时，远程调试 unwinder 读取到目标进程的损坏内存会导致 SIGSEGV——缺乏对远程读取数据的边界检查。

修复：PR #143190（3.15.0a4）——对所有远程读取的数据结构添加健壮性校验。

错误处理路径缺失（gh-144316, gh-146308）

问题：_remote_debugging 模块中多处错误处理缺陷：

• RemoteUnwinder.get_stack_trace() 在 debug=False 时可能返回 NULL 但不设置异常
• varint 解码路径缺少错误检查
• PyMem_RawMalloc() 返回 NULL 时缺少 PyErr_NoMemory() 调用
• 跨平台错误传播不一致

修复：PR #144442 和 PR #146309——全面审计并修复错误处理路径，set_exception_cause 宏改为无条件设置异常。

权限问题：sudo 创建的临时文件不可读（gh-143511）

问题：使用 sudo 运行注入脚本时，NamedTemporaryFile 以 root 用户创建（权限 0600），非 root 的目标进程无法读取该脚本文件。这是 PEP 768 "仅接受文件路径"设计的副作用。

处理：文档化（PR #143575）——用户需确保脚本文件对目标进程可读，或以相同用户运行。

Remote PDB 无法中断死循环（gh-132975）

问题：在远程 PDB 提示符下输入 while True: pass 后无法中断——能中断脚本本身的执行，但无法中断 PDB 命令求值中的死循环。

修复：PR #133223（3.14.0b1）——实现基于 socket 的中断机制：Unix 上发送 SIGINT 到远程进程，Windows 上通过 socketpair 传递信号。

审计事件缺失（gh-135543）

问题：sys.remote_exec() 最初未触发审计事件，安全工具无法监控进程注入行为。

修复：PR #135544（3.14.0b1）——添加 sys.remote_exec 审计事件，参数为 (pid, script)。

外部工具跟进

• debugpy（VS Code）：已支持 sys.remote_exec()（2026.1），Python 3.14+ 优先使用原生 API，可通过 --disable-sys-remote-exec 回退
• helicopter-parent：社区工具，通过管理子进程绕过 ptrace_scope 限制
• peeka/memray：已集成 PEP 768 作为首选注入路径

5. 三代方案对比

memray vs peeka 的容错策略

两个项目虽然共享 dlopen + pthread 的核心方案，但在失败处理上有本质区别：

memray：一次选择，不回退。 memray 在启动时通过 resolve_debugger() 按优先级（sys.remote_exec > gdb > lldb）选定一种注入方法，此后不再切换。GDB 路径硬依赖 C 扩展（assert injecter.exists()），dlopen 失败直接报错，没有 legacy 回退。这是刻意的设计选择——memray 作为专业的内存分析器，对运行环境有明确的前置要求。

peeka：逐级降级，尽力而为。 peeka 的决策树包含多层 fallback：

# peeka 的 attach 决策树
if hasattr(sys, "remote_exec"):     # Python 3.14+
    -> sys.remote_exec()              # 最优路径
elif _has_injector():                # C 扩展可用
    if Linux:
        try:
            -> GDB + dlopen + pthread # 安全回退
        except (TimeoutError, ...):
            -> GDB + PyRun_SimpleString  # 降级到 legacy
    elif macOS:
        -> LLDB + dlopen + pthread
elif Linux:
    -> GDB + PyRun_SimpleString       # 最后手段
else:
    -> 报错

这种设计源于 peeka 的定位——作为通用诊断工具，它需要在各种环境下都能工作，包括 GLIBC 版本不匹配（C 扩展无法加载）或 GIL 死锁（dlopen 路径超时）等边缘情况。代价是多了一层复杂度和潜在的时机安全风险（legacy 路径），但换来了更广的兼容性。

6. 实践中的坑

在实际开发 peeka 的过程中，我们踩过一些有趣的坑：

6.1 GLIBC 版本不匹配

C 扩展 _inject.abi3.so 在高版本 Linux 上编译后，放到低版本容器（如 Python 3.8 的 Debian 旧镜像）中会因为 GLIBC_2.34 not found 而 dlopen 失败。

但 importlib.util.find_spec() 只检查文件是否存在，不检查能否加载：

# ❌ 错误：文件存在但无法加载
def _has_injector():
    return importlib.util.find_spec("peeka.core._inject") is not None

# ✅ 正确：实际尝试 import
def _has_injector():
    try:
        import peeka.core._inject
        return True
    except (ImportError, OSError):  # OSError 捕获 dlopen 失败
        return False

6.2 GDB dlopen 后的 GIL 死锁

在 Python 3.12 上，GDB dlopen 注入的 C 扩展创建的 pthread 调用 PyGILState_Ensure() 时，可能因为 GDB 操作后 GIL 状态不一致而永远无法获取 GIL。

解决方案是将 dlopen 路径视为乐观尝试，失败后回退到 legacy GDB：

if _has_injector():
    try:
        return self._inject_via_gdb_dlopen()
    except (TimeoutError, RuntimeError, OSError):
        logger.warning("GDB dlopen failed, falling back to legacy GDB")
# 控制流落入 legacy 路径

6.3 ptrace 权限

不同 Linux 发行版的默认 ptrace_scope 不同：

Docker 容器默认不授予 CAP_SYS_PTRACE，且 seccomp 配置也会阻止 ptrace 系统调用。需要：

docker run --cap-add=SYS_PTRACE --security-opt seccomp=unconfined your-image

6.4 sys.monitoring tool_id 冲突

Python 3.12+ 的 sys.monitoring 只有 6 个 tool slot（0-5）。如果 coverage 工具或 debugger 已经占用了 slot 0，硬编码 use_tool_id(0, ...) 会抛 ValueError。应该遍历可用 slot：

for candidate_id in range(5, -1, -1):
    try:
        sys.monitoring.use_tool_id(candidate_id, "peeka-trace")
        break
    except ValueError:
        continue

7. 总结

Python 进程注入经历了三代演进：

1. 直接调用 C API（pyrasite）：简单粗暴，但有崩溃和死锁风险
2. dlopen + pthread（memray/peeka）：通过安全断点和独立线程显著降低风险
3. 解释器原生支持（PEP 768）：从根本上解决问题，让解释器自己在安全时机执行代码

如果你的目标环境是 Python 3.14+，sys.remote_exec 是毫无争议的最佳选择。如果需要支持更老的版本，dlopen + pthread 方案提供了合理的安全性和兼容性平衡。

进程注入不是魔法，它是系统编程、编译器原理和 CPython 内部机制的交汇点。理解这些底层原理，能帮助你在遇到"进程卡死"或"注入失败"时，快速定位问题所在。

本文基于 peeka 的实际开发经验撰写。peeka 是一个受 Alibaba Arthas 启发的 Python 运行时诊断工具，支持 Python 3.8-3.14+。