trampoline 的核心作用是绕过 w^x 内存保护，使数据指针能安全转为可执行函数指针，支撑闭包在现代系统上运行；它通过复用只读 trampoline 代码+轻量数据区来间接降低频繁闭包创建的开销。
Trampoline 包装器本身不用于“减少闭包创建开销”，它解决的是另一类更底层的问题：**让数据指针能安全地变成可执行函数指针**，从而支撑闭包机制在现代操作系统上运行。换句话说，它不是优化闭包的“数量”或“速度”，而是让闭包“能跑起来”。
Trampoline 的真实作用是绕过 W^X 内存保护
现代系统（如 macOS、Linux with SELinux、Windows DEP）默认禁止同一块内存同时可写（Write）又可执行（Execute）。而 libffi 闭包需要：
- 一块内存存状态（比如捕获的变量、回调函数地址、用户传入的
void*ctx）→ 需要可写 - 另一块紧邻或关联的内存存跳转指令（trampoline）→ 需要可执行
Trampoline 就是那段极小的、平台特定的汇编代码（通常 20–50 字节），它不做业务逻辑，只干三件事：
- 从固定偏移处读取闭包数据区地址
- 加载用户回调函数指针和上下文指针
- 跳转过去，并按目标调用约定传递参数
它如何间接降低“重复闭包开销”？
如果你频繁创建相同签名、相同行为的闭包（比如注册大量事件处理器），可以复用同一个 trampoline 实例 + 不同的数据区，而不是每次 malloc+write+protect 一套全新内存。关键在于：
- trampoline 代码本身是只读且可共享的——只要函数签名一致，一份 trampoline 可服务多个闭包
- 真正需要动态分配的，只是轻量级的数据区（通常几十字节），里面只存函数指针和 context 指针
- libffi 的
ffi_closure_alloc默认会为每个闭包分配独立内存；但高级用法中，你可以预分配一个 trampoline 池，再按需绑定不同数据区
实际编码中怎么靠近这个优化？
直接手写 trampoline 不现实，但可通过 libffi 的稳定接口控制生命周期：
- 用
ffi_closure_alloc分配一次闭包内存后，不要频繁 free/realloc；对短期回调可复用 - 避免在热循环里创建闭包——把闭包对象提到外层作用域，或用静态/全局闭包实例
- 确认你的 target 平台是否启用 mmap 分离段（
PROT_READ|PROT_EXEC+PROT_READ|PROT_WRITE）；若用 malloc 模拟，则性能损失明显，此时 trampoline 复用收益更大 - 在 WASM 或嵌入式环境（如微信小游戏）中，由于无传统内存保护，trampoline 可能被简化甚至省略，但闭包仍需状态区+跳转逻辑，此时重点应放在减少
ffi_prep_closure调用频次
注意：这不是 JavaScript 或 Python 里的“闭包优化”
前端或脚本语言中的闭包开销主要来自作用域链维护、变量捕获、GC 压力；而 libffi 的闭包是 C 层的零成本抽象，它的“开销”本质是内存分配与 mprotect 系统调用。Trampoline 是应对硬件/OS 限制的必要桥梁，不是性能开关——用对了，它让闭包可行；滥用或误解，反而引入额外 indirection 和 cache miss。
