SWIG不直接生成可运行绑定，只产出胶水代码；Python需手动编译为_underline_module.so并匹配命名与链接标志，Java须正确配置JNI库路径及System.loadLibrary名称，C#应确保调用约定、导出声明与DllImport一致。
SWIG 本身不直接生成“开箱即用”的多语言绑定，它生成的是胶水代码（C/C++ wrapper），再由对应语言的构建系统编译成可调用模块。能否成功，关键不在 SWIG 命令本身，而在你是否正确桥接了生成代码与目标语言的 ABI 和构建链。
如何让 SWIG 生成 Python 可导入的 _module.so（Linux/macOS）或 _module.pyd（Windows）
SWIG 不负责编译，只生成 .cxx 和 .py；你必须自己调用编译器并链接 Python C API。常见失败点是未传递正确的 Python 头文件路径和链接标志。
- 先用
swig -c++ -python -o example_wrap.cxx example.i生成胶水代码 - 确保
python3-config --includes输出的路径被传给-I，例如：-I/usr/include/python3.10 - 链接时必须包含
-lpython3.10（版本需匹配）且加-shared -fPIC - 生成的动态库名必须为
_example.so（注意下划线前缀），否则import example会报ModuleNotFoundError
g++ -shared -fPIC example_wrap.cxx example.cpp \ `python3-config --includes` \ -lpython3.10 -o _example.so
为什么 swig -java 生成的代码编译后 Java 调用时报 UnsatisfiedLinkError
Java 绑定依赖 JNI，SWIG 生成的 example_wrap.cxx 必须与 JVM 的 JNI 接口严格对齐，而错误通常出在加载时机或库路径上。
-
swig -java -package com.example example.i会生成example.java、exampleJNI.java和example_wrap.cxx - 编译 C++ 侧时，必须链接
jvm库（路径通常在$JAVA_HOME/jre/lib/amd64/server/libjvm.so或 macOS 的libjvm.dylib） - Java 运行时需通过
-Djava.library.path=.指明 native 库位置，且System.loadLibrary("example")中的名称必须与生成的libexample.so（Linux）或libexample.dylib（macOS）一致 - 不要手动修改
exampleJNI.java中的native方法签名，SWIG 生成的签名含包路径哈希，改错会导致 JNI 找不到函数
C# 绑定中 swig -csharp 为何常出现 P/Invoke 调用崩溃？
SWIG 默认生成的是 C 风格导出函数（extern "C"），但 C# 的 [DllImport] 若未指定调用约定或字符编码，容易因栈失衡或字符串乱码崩溃。
立即学习“Java免费学习笔记（深入）”；
- 务必在接口文件
.i中启用 Unicode 支持：%define SWIG_CSHARP_UNMANAGED_UNICODE - 生成时加
-dllimport参数，让 SWIG 在 C# 侧自动添加[DllImport("example.dll", CallingConvention = CallingConvention.Cdecl)] - C++ 侧导出函数必须用
extern "C"封装，避免 C++ name mangling；若用类方法，需额外封装为 C 函数或启用%csnothrow处理异常 - Windows 上 DLL 必须用
__declspec(dllexport)导出，Linux/macOS 则用-shared -fPIC编译为libexample.so，C# 侧[DllImport]名称要完全匹配
真正卡住人的往往不是 SWIG 语法，而是每个语言对符号可见性、ABI 约定、运行时加载路径的隐式要求。Python 看头文件和 .so 命名，Java 看 JNI 库路径和 System.loadLibrary 名字，C# 看调用约定和导出声明——三者互不相通，必须各自闭环验证。
