第1章 Rust与Python混合编程概述

第1章：Rust与Python混合编程概述

说实话，我第一次把Rust和Python放在一起用，是在一个数据处理项目里。Python写起来是真快，但跑起来是真慢。我当时盯着那个跑了快两小时的脚本，心想：这不行，得找个办法提速。

后来我试了Rust。性能确实猛，但开发效率嘛...你懂的。于是我开始琢磨：能不能让Python做它擅长的事——快速原型、胶水逻辑，让Rust处理那些计算密集的部分？

嗯，这就是混合编程的由来。

为什么需要混合编程？

说白了，就是各取所长。Python的优势在于生态丰富、上手快、写起来爽。Rust的优势在于性能强悍、内存安全、无GC开销。把它们结合起来，你就能得到：

开发效率 + 运行效率：Python负责业务逻辑，Rust负责性能瓶颈
安全与速度兼得：Rust的内存安全保证，Python的灵活调用
渐进式优化：先拿Python跑通，再把热点代码换成Rust

核心观点：混合编程不是炫技，是解决实际问题的工程手段。我在项目中见过太多人一上来就用Rust重写全部，结果工期翻了三倍。正确的做法是：先分析瓶颈，再局部替换。

应用场景分析

哪些场景适合混合编程？我根据自己的经验，总结了几个典型场景：

1. 计算密集型任务

比如图像处理、数值计算、加密解密。Python的循环慢得让人抓狂，换成Rust后，速度能提升几十倍甚至上百倍。

2. 系统级操作

需要直接操作内存、调用系统API、处理硬件时，Python的GIL和动态类型就成了障碍。Rust的零成本抽象和精确控制正好补上这块短板。

3. 现有Python项目的性能优化

项目已经用Python写好了，跑得也还行，就是某些模块太慢。这时候用Rust重写那几个模块，比全部重写划算得多。

4. 跨语言服务集成

有些底层库只有C/C++版本，但你想在Python里用。Rust可以充当桥梁，既安全又高效。

我的建议：别一上来就想着混合编程。先问问自己：这个模块真的是性能瓶颈吗？如果是，再考虑用Rust。我曾经见过有人为了提速一个只跑一次的数据清洗脚本，折腾了两天Rust绑定...得不偿失。

技术选型对比：PyO3 vs ctypes vs CFFI

好，现在你决定要混合编程了。那用什么工具？目前主流的有三个：PyO3、ctypes、CFFI。我一个个说。

特性	PyO3	ctypes	CFFI
语言支持	Rust原生	C库	C库
性能	极高（零开销抽象）	中等（有FFI开销）	较高（比ctypes略好）
开发体验	优秀（自动生成绑定）	繁琐（手动声明类型）	中等（需写C声明）
类型安全	强（编译期检查）	弱（运行时检查）	中等
生态成熟度	快速成长	非常成熟	成熟
适用场景	Rust + Python新项目	调用现有C库	需要精细控制FFI

PyO3：我的首选

如果你是用Rust写Python扩展，PyO3几乎是不二之选。它让你用Rust写一个Python模块，然后直接在Python里import。类型自动转换、错误处理、GIL管理，全都帮你搞定了。

// Rust端：用PyO3定义一个Python模块
use pyo3::prelude::*;

#[pyfunction]
fn fibonacci(n: u64) -> u64 {
    match n {
        0 | 1 => 1,
        _ => fibonacci(n - 1) + fibonacci(n - 2),
    }
}

#[pymodule]
fn my_math(_py: Python, m: &PyModule) -> PyResult<()> {
    m.add_function(wrap_pyfunction!(fibonacci, m)?)?;
    Ok(())
}

# Python端：直接导入使用
import my_math
print(my_math.fibonacci(30))  # 速度比纯Python快几十倍

避坑指南：我曾经在PyO3里忘记处理Python异常，结果Rust端panic了，整个Python进程直接崩掉。记住：在Rust里调用Python对象时，一定要用PyResult做错误处理。

ctypes：老牌工具

ctypes是Python标准库的一部分，不需要额外安装。它可以直接加载动态链接库（.so/.dll），然后调用里面的C函数。但问题是：你得手动声明每个函数的参数类型和返回类型，写起来很累。

# Python端：用ctypes调用C库
import ctypes

lib = ctypes.CDLL('./libmath.so')
lib.fibonacci.argtypes = [ctypes.c_uint64]
lib.fibonacci.restype = ctypes.c_uint64

result = lib.fibonacci(30)
print(result)

ctypes的好处是简单直接，坏处是类型不安全。你写错一个类型声明，运行时才会报错，而且错误信息往往很模糊。

CFFI：折中方案

CFFI介于PyO3和ctypes之间。它需要你写C语言的声明，但比ctypes更灵活，性能也更好。它支持两种模式：ABI模式（直接加载二进制）和API模式（编译时生成绑定）。

# Python端：用CFFI调用C库
from cffi import FFI

ffi = FFI()
ffi.cdef("""
    uint64_t fibonacci(uint64_t n);
""")

lib = ffi.dlopen('./libmath.so')
result = lib.fibonacci(30)
print(result)

注意：CFFI的API模式需要编译C代码，但性能最好。ABI模式虽然方便，但跨平台兼容性差。我建议：如果你要发布给用户用，用API模式；如果只是自己调试，ABI模式就够了。

怎么选？我的经验法则

说了这么多，到底选哪个？我一般按这个逻辑判断：

新项目，用Rust写扩展 → 选PyO3。开发体验最好，性能也最强。
已有C库，想快速调用 → 选ctypes。标准库自带，不用折腾编译环境。
需要精细控制FFI，或者跨平台 → 选CFFI。灵活性高，但学习成本也高。
性能要求极高，且愿意折腾 → 还是PyO3。它的零成本抽象不是吹的。

我个人习惯是：能用PyO3就用PyO3。ctypes和CFFI虽然也能用，但写起来太啰嗦，而且容易出bug。你想想看，一个类型声明写错了，排查半天才发现，多浪费时间。

本章知识体系

下面这张图，是我梳理的本章核心逻辑。你可以把它当作一个决策地图：

这张图的核心逻辑是：先确定你的应用场景，再选择合适的技术方案。我个人建议，除非你有特殊需求（比如必须调用已有的C库），否则优先考虑PyO3。

一个小技巧：刚开始接触混合编程时，可以先拿一个简单的函数练手，比如斐波那契数列。这样既能熟悉工具链，又能直观感受到性能提升。我当年就是这么入门的。

公众号:蓝海资料掘金营，微信deep3321

📚 课程目录