PyPy显著加速纯Python计算密集型代码的核心原因是其JIT编译器仅对高频执行的热点代码（如长循环、递归、自定义算法）动态编译为机器码，而CPython始终逐行解释执行；但PyPy不加速C扩展调用（如numpy、pandas、数据库操作），且冷启动慢、C扩展兼容性有限。
PyPy 能显著加速纯 Python 计算密集型代码，但不是所有项目都适合直接替换 CPython。是否值得切换，取决于你的程序热点在哪、用了哪些第三方库、以及运行环境是否支持。
确认你的性能瓶颈真在 Python 解释器层
很多项目慢，其实和 CPython 关系不大：SQL 查询、HTTP 请求、文件 I/O、调用 numpy/pandas 等 C 扩展才是耗时大头。这些部分换 PyPy 不仅不加速，反而可能更慢。
先用 py-spy record -o profile.svg --pid $PID 或 cProfile 看热点函数是不是集中在纯 Python 循环、字典操作、自定义类方法等——只有这类场景，PyPy 的 JIT 才能生效。
- 适合：大量 for 循环、递归、字符串处理、自定义算法逻辑
- 不适合：主要时间花在
requests.get()、pd.read_csv()、cursor.execute()上 - 典型反例：Django/Flask 项目若 80% 时间在数据库查询，换
PyPy基本无感
安装与验证 PyPy 是否正常工作
别用包管理器装（比如 conda install pypy 可能版本旧或带补丁），直接去 pypy.org/download.html 下载对应平台的预编译包（推荐 PyPy3.10 v8.0+，兼容 Python 3.10 语法且 JIT 更成熟）。
解压后把 pypy 可执行文件路径加进 $PATH，然后运行：
立即学习“Python免费学习笔记（深入）”；
pypy --version pypy -c "import sys; print(sys.implementation.name)"
输出应为 pypy，不是 cpython。再试跑一段纯循环代码，对比 python script.py 和 pypy script.py 的耗时，确认基础加速有效（通常 3–7 倍，取决于循环深度和数据规模）。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
检查关键依赖是否兼容
PyPy 兼容绝大多数纯 Python 库（requests、flask、sqlalchemy），但对依赖 CPython C API 的扩展支持有限：
- 明确不支持：
pyinstrument（profiler）、sshtunnel、lxml（需用pip install lxml --no-binary lxml源码编译）、psycopg2（推荐换psycopg，纯 Python 实现） - 性能倒退：
numpy、pandas、scipy—— 它们底层是 C/Fortran，PyPy的 JIT 无法优化，且其内存模型与 CPython 不同，调用开销更大 - 需测试：
gevent、ujson、cryptography（新版大多已适配，但务必本地跑通单元测试）
最稳妥方式：用项目现有 requirements.txt 在干净虚拟环境里执行 pypy -m pip install -r requirements.txt，失败项单独查文档或 issue。
部署时注意运行时差异
PyPy 默认启用 stackless 模式，协程行为、栈深度限制、GC 触发时机都和 CPython 不同：
- 递归深度默认更高，但过度递归仍会
RecursionError；可用sys.setrecursionlimit()调整，效果不如 CPython 稳定 -
gc.collect()行为更激进，某些依赖弱引用或对象析构顺序的代码可能出错 -
threading.local在多线程下表现一致，但gevent+PyPy组合需额外验证 greenlet 兼容性 - 日志中看到
__pypy__模块存在，说明运行在 PyPy 环境，可据此做条件分支（如绕过不兼容模块）
线上切流前，务必用真实流量做 A/B 对比：相同请求路径、相同参数、记录响应时间 P95/P99 和错误率。尤其关注长连接、定时任务、内存增长曲线——PyPy 的 GC 策略可能导致内存占用波动更明显。
真正容易被忽略的是：PyPy 的启动时间比 CPython 长，冷启动服务（如 AWS Lambda）可能多出 100–300ms；而它带来的收益，只在持续运行、反复执行热点代码时才稳定兑现。
