第2章 绑定技术栈概览
做加密SDK的多语言绑定，说白了就是在不同语言之间搭桥。C/C++写的核心密码算法，要能被Java、Python、C#、Kotlin这些语言调用，就得靠一套绑定技术。我在安全SDK项目里折腾过五六种绑定方案，哪种好用、哪种坑多，心里还是有点数的。
2.1 为什么需要这么多技术？
你想想看，Java有JVM，Python有解释器，C#有CLR，Kotlin有Native编译……每个语言的运行时差异太大。没有一种绑定技术能通吃所有场景。我曾经在同一个项目里同时维护JNI和ctypes两套绑定，就是因为Java和Python的底层机制完全不同，硬要用同一套工具反而更痛苦。
下面这张图是我给团队做技术选型时画的，帮你快速理解当前主流绑定方案的分层关系：
2.2 七个核心技术，一个一个掰开看
下面这张表是我自己整理的对比维度。你先扫一眼，我再挑几个重点展开聊。
| 技术 | 目标语言 | 实现原理 | 性能 | 学习成本 | 我的评价 |
|---|---|---|---|---|---|
| JNI | Java/Kotlin(JVM) | JVM原生接口，C函数直调 | 极高（零开销） | 高（需熟悉JNI规范和签名） | 很稳，但写起来像在受刑 |
| ctypes | Python | 运行时FFI，加载.so/.dll | 中等（调用有额外开销） | 低（纯Python声明） | 简单粗暴，但复杂结构体很头疼 |
| CFFI | Python | C头文件解析生成绑定 | 较高（ABI/API模式可选） | 中（需写少量C声明） | 比ctypes优雅，我偏好API模式 |
| pybind11 | Python | C++头文件模板元编程 | 极高（内联优化） | 中（需要C++11+） | 现代C++项目首选 |
| SWIG | 多语言（Java/Python/C#等） | 接口定义文件(.i)生成胶水代码 | 较高（生成代码较通用） | 中（.i文件语法需学习） | 一个工具绑多语言，但处理模板类很痛苦 |
| CppSharp | C# (/.NET) | 解析C++ AST生成C# P/Invoke | 高（接近手写P/Invoke） | 中低（自动程度高） | .NET生态里我常用这个 |
| Kotlin/Native | Kotlin (非JVM) | LLVM编译，直接链接C库 | 极高（无运行时桥接） | 中（需要cinterop配置） | KMP跨平台开发的利器 |
2.3 说说我的实战感受
JNI 是我最早接触的绑定方式。说实话，写JNI就像在写Java和C的混血儿——签名编码、类型映射、局部引用管理，稍不留神就内存泄漏。我记得有一次排查了一整天，最后发现是没正确处理GlobalRef。JNI的问题不是你写不了，而是你一旦接手的项目有10个JNI函数，维护成本就直线飙升。所以我的建议是：除非你的加密SDK核心逻辑极其稳定，否则别轻易用纯JNI。
ctypes 在Python圈子里用得很广。我一个数据加密工具需要快速验证，直接用ctypes加载动态库，十分钟搞定。但它有两个明显短板：一是复杂结构体需要手动定义 layout，嵌套结构容易出错；二是调用性能不如 CFFI 的 API 模式。如果你的SDK接口参数简单，ctypes挺合适的；但一旦涉及回调函数或自定义内存管理，我劝你换成 CFFI。
pybind11 是我现在最常用的 Python 绑定方案。为什么？因为它能直接操作C++对象，甚至支持智能指针和自动转换。我做过一个测试，pybind11 生成的绑定调用开销几乎等于直接调用C函数，比 ctypes 快 3-5 倍。不过注意，它需要编译器支持 C++14，如果你的 CI 环境还在用 GCC 4.8……嗯，还是老老实实 ctypes 吧。
CppSharp 在 .NET 圈里值得一提。我之前把一个 C++ 加密库绑定给 C# 用，手写 P/Invoke 写了三天，后来用 CppSharp 重写了绑定描述文件，十分钟生成全部代码。它自动处理了大部分类型映射，尤其是 STL 容器的转换。但注意，它对 C++ 模板特化的支持还不够完善，遇到复杂的模板库可能会报错。
SWIG 是个老牌工具，一个 .i 文件就能生成 Java、Python、C# 等多语言绑定。但我在项目里吃过亏——它生成的 Java 代码里有很多 JNI 辅助类，导致最终 APK 体积增大 2MB。而且一旦接口定义文件写错，生成的代码调试起来非常痛苦。我现在的原则是：如果只绑一个语言，别用 SWIG；如果必须绑三个以上，可以考虑。
Kotlin/Native 是我最近研究的一个方向。它用 cinterop 工具直接解析 C 头文件生成 Kotlin 绑定，而且编译后是原生机器码，性能极佳。缺点是对 C++ 支持有限，只能通过 C 接口桥接。如果你在写 Kotlin Multiplatform 的加密 SDK，这是最自然的方案。
2.4 选型建议
给你一个我自己的决策思路：
- 目标语言是 Python：首选 pybind11（C++项目）或 CFFI（纯C项目），别用 ctypes 做生产级。
- 目标语言是 Java/Kotlin (JVM)：如果团队有 C功底且接口稳定，JNI 可行；否则用 SWIG 或者考虑 JNR-FFI。
- 目标语言是 C#：直接上 CppSharp，避免手写 P/Invoke。
- 目标语言是 Kotlin Native：cinterop 是正统方案，但注意只能绑定 C 接口。
- 多语言同时发布：SWIG 能一劳永逸，但要接受生成代码的臃肿和调试难度。
int crypto_init(const char* config)）作为测试桩。这个函数可以用任何一种绑定技术验证调用通路，等通路通了再封装 C++ 对象。这样能最快发现绑定层的问题，而不是把时间浪费在排错上。
好了，这七种绑定技术各有利弊，没有银弹。我的经验是：先搞清楚你的目标运行时、性能敏感度和团队技术栈，再动手。下一轮我们专门挑 JNI 和 pybind11 深入讲底层原理。今天就先到这儿。