PyO3 本身不提升性能，仅实现 Rust 与 Python 互操作；真正加速需将计算密集、无 GIL 依赖的部分移出 Python，否则徒增调用开销。
PyO3 本身不是性能“突破器”，它只是让 Rust 代码能被 Python 调用；真正的性能提升，取决于你是否把**计算密集、有明确边界、无 GIL 依赖**的部分移出了 Python —— 否则只是多了一层调用开销。
什么时候该用 PyO3 而不是 ctypes 或 cffi
当你需要频繁传递复杂数据结构（如 Vec、HashMap、自定义 struct），或要暴露 Rust 的泛型/生命周期语义给 Python 时，PyO3 的 #[pyclass] 和 #[pymethods] 比 ctypes 的手动内存管理更安全、比 cffi 的 Python 端 glue 代码更紧凑。但若只是调用一个纯 C 函数，ctypes.CDLL 通常更快、更轻量。
- PyO3 适合：需要在 Python 中自然使用 Rust 类型（如返回
PyResult<Py<PyList>>）、做异步绑定（#[pyo3(async)]）、或集成async-std/tokio - 避免用 PyO3：只做一次简单数值计算，且输入输出全是
f64或i32数组 —— 这类场景用numpy.ndarray+ctypes零拷贝映射更直接 - 注意：
PyO3默认启用auto-initialize，若嵌入到已有 Python 进程（如 Blender、Maya），需显式关掉，否则可能触发Py_Initialize: initialization failed
如何避免 GIL 释放失效导致的假并发
很多人加了 #[pyfunction(release Gil)] 却发现 CPU 占用没上去，问题常出在 Rust 函数内部仍意外持有 Py<T> 或调用了 Py::as_ref() —— 这些操作会隐式重新获取 GIL。
- 释放 GIL 仅在函数签名不含任何
Py<T>、&PyAny、&PyModule等 Python 对象引用时才真正生效 - 若必须传入 Python 对象（如回调函数），改用
PyObject并在函数开头用unsafe { py.allow_threads(|| { ... }) }手动控制临界区 - 验证是否真释放：在 Rust 函数内 sleep 1 秒，同时在 Python 启另一个线程
threading.Thread(target=time.sleep, args=(0.1,)).start()，观察是否能抢占执行
字符串和数组传递的零拷贝陷阱
Python 的 str 是 UTF-8，但 Rust 的 &str 也是 UTF-8 —— 表面兼容，实际 PyO3 默认会做完整 clone；而 numpy.ndarray 默认是 C-contiguous，但 Rust 的 ndarray::ArrayView 若未指定 Order::C，可能因内存布局不匹配导致越界读。
立即学习“Python免费学习笔记（深入）”；
- 传字符串：用
#[text_signature = "(s: str)"]+ 参数类型设为String（强制拷贝）或&str（借用，但需确保 Python 字符串生命周期足够长）；更安全的做法是接收PyBytes，再用std::str::from_utf8_unchecked（仅当确定是 UTF-8） - 传数组：优先用
PyArray<f64, D2>（来自pyo3-numpycrate），它能直接访问 numpy 的 data ptr，无需 copy；避免用Vec<f64>接收，那会触发完整内存复制 - 警告：
PyArray::as_array()返回的是ndarray::ArrayView，不是所有权转移，别在闭包里存它的引用并跨线程用
最难的从来不是写通 PyO3，而是判断哪段逻辑值得搬过去 —— 很多号称“加速 10 倍”的案例，实际只是把原本就该用 Rust 写的算法从 Python 翻译了一遍；如果原 Python 实现本身用了大量 list.append 或 dict 随机查找，换 Rust 后收益有限，不如先用 numpy 或 numba 优化。
