c++无法直接调用jittor或taichi的aot编译结果，因其动态库强依赖python运行时；taichi自1.6.0起支持c-api模式导出纯c接口供c++安全调用，而jittor目前无等效机制，只能通过onnx中转或重写核心逻辑。
为什么不能直接在 C++ 里用 Jittor 或 Taichi 的 AOT 编译结果
Jittor 和 Taichi 都是 Python 优先的 DSL 框架，它们的 AOT 编译产物（比如 taichi.aot.Module 导出的 .so / .dll）本质是带 Python 胶水层的动态库，不是纯 C++ 可链接的 ABI。C++ 程序直接 dlopen 或链接会失败，因为符号依赖 libpython、PyBind11 注册表、以及框架内部的 runtime 单例（如 TaichiRuntime 实例）。
想让 C++ 调用 Taichi AOT 模块：必须绕过 Python runtime
Taichi 从 1.6.0 起支持「C-API mode」，导出纯 C 函数接口，这才是 C++ 可安全调用的路径。Jittor 目前（v1.4.x）没有等效机制，它的 AOT 输出仍强绑定 PyTorch 和 Python 解释器。
- 导出时加
module.save_c_header = True，生成taichi_aot.h和libtaichi_aot.so - C++ 代码用
extern "C"包裹头文件，避免 name mangling - 必须手动调用
taichi_create_runtime初始化，再传给taichi_kernel_launch，不能省略 - GPU 后端（CUDA/Vulkan）要求 C++ 进程已初始化对应驱动环境（比如先调
cudaSetDevice）
Jittor 在 C++ 中基本不可行，替代方案只有重写核心逻辑
Jittor 的 IR 生成、自动微分、内存调度全部耦合在 Python 的 jit 装饰器和 nn.Module 生命周期里。它不提供 C 接口头文件，也不打包 runtime 到独立库。即使强行把 libjittor.so 加载进 C++ 进程，也会因缺失 PyThreadState 崩溃。
- 若已有 Jittor 模型训练代码，只能用 Python 侧导出 ONNX，再用
onnxruntime在 C++ 中推理 - 若只是需要高性能 dataflow（如 stencil 计算），直接用 Taichi 的 C-API 或原生 OpenMP/CUDA 更可控
- 别尝试 patch
pybind11binding —— Jittor 的 tensor 内存布局和 Python GC 交互太深，C++ 指针一碰就 dangling
真正能落地的 C++ dataflow 方案：Taichi C-API + 手动内存管理
这是目前唯一兼顾开发效率和 C++ 集成度的路径。关键不是“怎么调用”，而是“怎么不依赖 Python 分配的内存”。
- 所有输入/输出 buffer 必须由 C++ 分配（
malloc或cudaMalloc），通过taichi_ndarray_t结构体传入 kernel - kernel 参数列表在 C header 里固定，但数组维度需在 C++ 侧按
shape[0], shape[1], ...显式填入ndarray->shape字段 - 调用
taichi_kernel_launch前，确保ndarray->device指向正确设备（TI_ARCH_CUDA对应 CUDA 上下文） - 常见坑：
taichi_aot.h里的 struct 定义可能随 Taichi 版本微调，建议用#include "taichi_aot.h"而非复制粘贴
复杂点在于 GPU 设备上下文生命周期管理——Taichi runtime 不帮你 hold 住 cudaStream_t 或 Vulkan VkCommandBuffer，这些得你自己的 C++ 代码管。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
