一个 Python 程序运行缓慢，原因可能在 Python 循环，也可能在数据库、磁盘或等待网络。换一种语言之前，先确定时间花在哪里。否则花几天改写计算代码，整个任务仍然在等远端接口返回。
Mojo 适合放进这种具体的性能问题里评估。它提供系统编程能力，也支持与 Python 双向互操作，可以让部分工作保留在现有 Python 项目中。本篇讨论怎样选择迁移范围、比较结果和处理部署，不把示例推算写成实际跑分。
时间信息也需要更新：Modular 于 2026 年 8 月 18 日宣布 Mojo 编译器与工具链开源，采用带 LLVM exceptions 的 Apache 2.0 许可；本文在 2026 年 9 月 23 日核查时，官方文档显示版本为 1.1.0。旧版教程中的语法和安装方式应与所用版本对照。开源公告 · 当前安装文档
先把慢的部分单独拿出来
假设一个批处理任务包括读文件、解析数据、计算特征和写结果。分别记录每一步耗时，就能知道优化应从哪里开始。还要看计算阶段内部：是在 Python 中逐个处理元素，还是主要调用已经优化过的 NumPy 运算。
如果大量时间已经花在底层数值库中，只把外层函数换成 Mojo 调用，未必有明显收益。若瓶颈是自己写的高频小循环，或多次中间结果分配，才值得拿出一个小范围做实验。目标最好能写成一句话，例如减少某个特征计算的总耗时，同时保持输出一致。
可以用一个简单推算帮助判断投入是否值得。假设某阶段占总时间的一半，并且这部分被加速到原来的十分之一，其余部分完全不变，那么总耗时会变为原来的 0.5 + 0.5 / 10 = 0.55，整体约快 1.82 倍。这里是理想化计算，不是 Mojo 的性能数据。
这个推算也说明测试范围为什么重要。只展示热点函数快十倍，却不报告整件任务的耗时，读者无法判断迁移收益。接口调用、数据复制和初始化还可能吃掉一部分节省下来的时间。
从 Mojo 调用 Python，保留的是生态入口
官方文档提供 Python.import_module 等互操作方式，让 Mojo 调用已有 Python 模块。这适合逐步试验：外围的数据读取和成熟依赖可以先保留，再单独实现需要优化的部分。从 Mojo 调用 Python
但通过互操作调用一个 Python 函数，仍然要考虑 Python 运行环境与对象语义。不能把普通 Python 循环导入之后，就认为它自动变成优化过的本地内核。要判断加速来自哪里，应区分自己用 Mojo 实现的计算与仍在 Python 侧执行的工作。
例如一项操作逐个读取 Python 列表元素，再频繁跨语言调用小函数，调用和转换成本可能很突出。可以考虑先把输入整理成批量数据，让一次调用完成较多计算。是否需要复制、能否共享数据，以及允许哪种布局，都必须由选定接口实际支持。
因此，第一个互操作实验只需验证几件事：目标模块能否导入，输入能否被正确接收，返回结果是什么类型，发生异常时调用方得到什么信息。先把接口接稳，再比较性能。
从 Python 调用 Mojo，接口尽量小
对已有业务，保留 Python 作为入口通常更容易逐步上线。官方也提供从 Python 调用 Mojo 的路径，具体绑定、导入和支持类型应按所用版本文档实现。从 Python 调用 Mojo
可以让一个函数接收一批数值，返回计算结果，而不是一开始暴露大量内部对象。小接口更容易为 Python 与 Mojo 分别建立测试，也便于保留旧实现作为对照。出现问题时，可以让调用方切回旧路径，而不必回退整个应用。
接口约定里需要写清数据类型、维度、缺失值处理和异常情况。例如空输入应该返回空结果还是报错，整数溢出怎样处理，浮点比较允许多大误差。Python 代码里一些依靠动态行为工作的情况，迁移后可能需要明确表达。
输出相近也不总是代表正确。计算顺序变化会影响浮点结果，应根据业务选择比较方法；如果结果用于金额、计数或索引，误差处理又有不同要求。先规定验收标准，再看测试结果，避免为了让新实现“通过”而临时放宽条件。
所有权要放在实际数据流里理解
Mojo 的所有权设计让值的借用、修改与转移更明确。对从 Python 开始学习的人，最容易卡住的地方通常不是一个语法符号，而是函数调用以后，谁还能使用或修改那份数据。所有权入门
学习时可以画一条很短的数据流：调用方创建输入，计算函数读取，返回方取得输出。如果函数需要修改输入，就把这一点写入接口；如果只读，就不要让调用方误以为原数据会变化。把这些关系与实际需求对上，比单独记忆关键字更容易理解编译器提示。
同时，不要把语言提供的检查扩展成所有程序都不会出错。越接近原始指针、外部接口或设备内存，越需要根据所用 API 检查生命周期与访问条件。算法是否正确、索引是否符合业务要求，也不能仅靠成功编译判断。
对于第一次迁移，尽量沿用较简单的数据所有权关系。不要同时改写算法、增加并行、引入复杂共享数据，然后试图从一次错误结果中判断是哪一层出了问题。
GPU 实验要把搬运与同步算进去
Mojo 提供面向 GPU 的编程能力，但“同一种语言”不等于所有硬件具有相同配置与性能。系统、设备和驱动要求应先查官方支持范围，不能因为 CPU 示例运行成功，就推断当前机器也能运行目标 GPU 示例。系统要求
测试时分别考虑首次准备、数据传输、计算和取回结果。只计内核执行时间，可能掩盖小任务的数据传输成本。对于异步执行，还要在正确的位置同步，否则计时可能只记录了提交工作，而没有等到计算完成。
工作量也要接近日常使用。一个极大数组容易显示并行收益，但应用实际每次只处理几十个元素，结论就未必适用。可以用小、中、大三种典型输入测试，并记录完整调用的耗时和内存使用。
如果数据原本已经在设备上，比较方案也要保持这个前提；若每次都从 CPU 传过去，就把这一成本一并计算。描述清楚这些条件，比给出一个脱离场景的加速倍数更有用。
安装成功以后，还要试一次干净环境
当前官方安装页提供 uv 与 pixi 路径，并列出 macOS、Linux 的系统要求。已有 uv 的情况下，可以在独立项目中添加 Mojo，固定依赖后再编译自己的小样本。不要把开发机里已有的 Python 包当成部署机也一定具备的条件。
本文没有运行 Mojo 编译器，因此不提供未经验证的代码片段与性能结果。实际试验时，先按当前官方示例验证互操作，再把自己的热点函数带进去；同时记录编译器版本、Python 版本、操作系统和硬件。
随后在一个没有开发缓存的环境中重新安装与运行。检查需要哪些动态库，包能否找到，错误信息是否足够定位问题。若只能在某位开发者的电脑里成功，就还没有完成部署验证。
升级工具链时也应重跑相同的正确性测试。文档当前显示的版本与团队固定的版本可能不同，遇到语法问题先确认使用了哪套文档，而不是直接混合不同发布时间的示例。
最后比较整件工作，而不只比较函数
一次评估可以保留两条实现：原来的 Python 路径与新的 Mojo 路径。两者读取相同输入，执行相同输出检查，分别记录初始化、稳定运行和完整任务的时间。首次编译或加载成本要单独列出，不能悄悄从其中一方删除。
还要记录人工维护成本：团队是否能读懂新代码，故障时能否定位，部署产物是否容易分发。如果性能收益只出现在很少发生的场景，而维护复杂度显著增加，暂时保留 Python 实现也是合理结果。
适合继续推进的情况通常很具体：热点已经确认，小接口能稳定接入，结果通过对照测试，整件任务也有可重复的改善。此时再扩大迁移范围，每次保留基准与旧路径。这样引入一门语言的决定，就来自自己的程序，而不是来自别人展示的单项跑分。