学 Python 快两年了，觉得这玩意儿是真顺手。想干点啥，几行代码就跑起来了，那种掌控感特别爽。但架不住总有人说 Python 慢，什么"Python 慢成狗""导包侠""调包侠"的梗满天飞，听了整整一年。后来我才发现——不是它不行，是我没搞懂它到底擅长什么。00 先说说我
我不是科班出身，编程就是纯爱好，觉得有意思就开始学了。学 Python 两年，自己瞎折腾了不少东西：React 写前端、Django 做权限管理、FastAPI 写接口、Redis 做缓存、MySQL 存数据、爬虫单独跑一个调度器。一开始确实是全靠自己，到处翻文档、看视频、啃源码，东一榔头西一棒槌地凑。后来卡在一个问题上死活过不去，机缘巧合碰到一个愿意教我的老师。他没给我写代码，也没给我安排项目，而是帮我理清了学习路线，丢给我一套系统的课程，告诉我该往哪走。我的第一个"实战项目"
老师给我布置的第一个任务，我到现在都记得清清楚楚——写一个百度图片爬虫，必须用 PyQt5 做 GUI，而且不准用 AI 辅助。那时候我连异步是什么都不知道，更别说 PyQt5 的信号槽机制了。我硬着头皮上，从 requests 发请求、解析 HTML、提取图片链接，到用 PyQt5 画界面、做进度条、处理点击事件……全是一行一行自己敲。写到异步下载那块，我彻底崩了。async/await 怎么都调不通，回调地狱里绕了三天三夜，代码删了写、写了删，凌晨三点对着屏幕发呆，脑子里只有一个念头：我是不是根本不适合干这个？我给远在大洋彼岸的老师发消息，写不出来有点想放弃的想法。"每一个程序员必须要走的一条路，一定要坚持住。你正在进入编程的深水区，要坚持住。程序员遇到困难一定要走出去，一直保持学习的心态。"
那天晚上我洗了个脸，重新打开编辑器，把异步的文档又啃了一遍。天亮的时候，进度条终于动了。当看到 GUI 界面上第一张图片被爬下来、显示在窗口里的那一刻，我差点从椅子上跳起来。那种成就感，比后面写的任何项目都强烈——因为这是我第一次真正靠自己，从 0 到 1 把一件事干成了，兴奋的给老师发了程序的视频，~哈哈，老师说了句，能吃技术这碗饭，以后要把技术练好，保持学习的心态，技术更新的很快，不保持终身学习的精神，很快就会被技术抛弃，加油。剩下的路，还要靠我自己走的。这次经历对我来说很重要，也对我的人生很重要，从此以后最爽的时候，就是看到自己写的代码跑起来那一刻。那种"这事儿我能搞定"的感觉，比打游戏拿五杀还爽。01 第一次感觉到"慢"
说回来python的慢，有一回我从一个开源数据集网站下了份数据，足足一千万条结构化记录，想写个脚本自己分析着玩。写完之后一跑——等了半天，还没出结果。然后我开始翻文档、搜优化技巧：列表推导代替 for、map 代替 for、multiprocessing 开多进程……能用的招全上了。是快了一点，但还是不够爽利。后来我又找了个爬虫靶场练手，跑了一万条数据，同样的感觉——等结果等到怀疑人生。直到后来我才知道，纯 Python 循环干 CPU 密集型的活，就好比拿菜刀砍柴——不是刀不行，是你没用对工具。这不怪 Python，它的设计目标从来就不是算得快。02 Python 到底慢在哪？
Python 是解释型语言，不是编译型的。它边解释边执行，不像 C 那样编译完了直接跑机器码。你写了个 a = 1，后面又写 a = "hello"，它照样能跑。但代价是：Python 得在运行时反复检查这个变量到底是什么类型。每次循环、每次运算，都多一道"类型检查"的工序。C 不需要，它在编译的时候就把类型定死了。你把 a 声明成 int，它就是 int，直接算。不是 Python 不想快，是它设计出来就不是来干这种裸循环的活的。这时候你可能要问了："不对啊，Python 的解释器 CPython 本身就是 C 写的，那为什么 Python 还是慢？"CPython 是 C 写的，但它干的是"翻译"的活，不是"执行"的活。C 代码是这样的：你写完之后编译成机器码，CPU 直接执行，没有中间商赚差价。// C 代码int a = 1;a = a + 1;
Python 代码是这样的：你写的是"高级指令"，CPython 解释器（C 写的）在运行时逐条读取、解析、翻译成字节码，再交给虚拟机执行。每一步都有额外的"翻译"开销。解释器读取 a = 1 → 解析语法 → 生成字节码 → 虚拟机执行解释器读取 a = a + 1 → 解析语法 → 生成字节码 → 虚拟机执行每一步都经过 CPython 解释器的"翻译层"，而这个翻译层本身就是 C 写的——但翻译过程本身消耗了额外的时间。你让 C 写的程序直接跑，和让 C 写的解释器去"翻译"你的代码再跑，速度差了一个数量级。这还不算动态类型的额外开销。C 语言里变量类型在编译时确定，编译器直接生成整数加法指令。Python 里每次加法都要先确认 a 是什么类型、支不支持加法、调用哪个加法函数——每次运算多了 4 道检查工序。C 语言的一个整数是 4 字节的内存块，直接操作。Python 的一个整数是 28 字节的对象，包含引用计数、类型指针等元数据。更大的内存占用意味着更慢的缓存命中率和更多的内存分配开销。所以：不是 C 不够快，是 Python 被迫在 C 的"翻译层"里绕了太多路。03 咱们来写段代码看看差距
为了让你直观感受，我写了一个最简单的任务：两个 1000×1000 的矩阵相乘。纯 Python 矩阵乘法def matmul_py(A, B): n = len(A) m = len(A[0]) p = len(B[0]) C = [[0.0] * p for _ in range(n)] for i in range(n): for j in range(p): for k in range(m): C[i][j] += A[i][k] * B[k][j] return C
这段代码跑完 1000×1000 的矩阵乘法，需要21850 毫秒（约 22 秒）。为什么这么慢？因为 Python 解释器每执行一次内层循环，都要做动态类型检查、列表索引边界检查、内存分配……三层嵌套循环下来，每轮内层循环产生约120 纳秒的额外延迟。累积起来就是十几秒的差距。04 那为什么 NumPy 快得离谱？
后来自己翻文档、看源码，才搞明白——NumPy 的"快"，根子上就不是 Python 的快。NumPy 的核心是用C 语言写的。你写 np.dot(A, B)，Python 只是打了个电话给 C 写的底层函数，真正算的是 C。而且 NumPy 还用上了SIMD（单指令多数据流），一条 CPU 指令同时处理多个数据。这玩意儿 Python 自己的循环根本做不到。因为人家在用 C 干活，你用 Python 自己干。用 NumPy 跑同样的 1000×1000 矩阵乘法，只需要36.2 毫秒。22 秒 vs 0.036 秒——差距 600 倍。05 一个深夜的发现
就在我一边优化 Python 代码、一边怀疑人生的时候，刷到了一条消息：2026 年 8 月 11 日，Mojo 1.0 正式发布。8 月 18 日，全部以 Apache 2.0 许可证开源。这语法……也太像 Python 了吧？缩进、for 循环、range、函数定义，几乎是一个模子刻出来的。但它不是解释执行，而是AOT 编译成机器码。支持指针——而且设计得很精细。Mojo 1.0 把指针统一成了单一的 Pointer 类型，所有危险操作都必须显式写 unsafe_ 前缀，比如 ptr.unsafe_load()、ptr.unsafe_store()。既能像 C 一样直接操作内存，又把"危险区域"标得清清楚楚。无 GC——所有权系统管理内存，编译时就能确定生命周期。这对系统级编程来说太重要了。我还顺手查了查嵌入式方向——AOT 编译、无 GC、原始内存访问，底层能力都具备，虽然官方主战场还是 AI/HPC，但树莓派级别的 Linux 嵌入式设备已经可以试试了。我看了一下文档，编程，最重要的就是动手实践，哈哈，直接上手把，遇到困难再说，写了几个 Hello World，又跑了几段基准测试。越玩越觉得，这东西的真正价值不是"让 Python 更快"，而是给 Python 兜个底——Python 不擅长的裸循环、指针操作、CPU 密集型计算，Mojo 能顶上去；反过来，Mojo 也不抢 Python 的活儿，Web、爬虫、胶水代码，该 Python 干还是 Python 干。06 然后 Mojo 来了——不是来取代 Python，是来兜底的
Python 不擅长的 CPU 密集型任务，总得有个东西来顶上去。Mojo 的定位很直接：受 Python 语法启发，但拥有编译型语言的性能。它是一门专为高性能计算设计的新语言，有自己的静态类型系统和所有权模型，并不是 Python 的"超集"或"替代品"。但 Mojo 做对了一件事：它不让你抛弃 Python 生态。你在 Mojo 里可以直接 import Python 的任何模块——NumPy、PyTorch、Pandas，全部能用。反过来，Mojo 也支持编译为共享库（.so）供 Python 调用，不过这项功能还在快速完善中，目前需要特定的模块构建流程。不需要学一套全新的生态，不需要重写整个项目。思路是：Python 负责搭架子，Mojo 负责填里最慢的那几块砖。07 来看看 Mojo 怎么写
fn matmul(a: Tensor[DType.float64], b: Tensor[DType.float64]) -> Tensor[DType.float64]: let m = a.shape[0] let n = b.shape[1] let k = a.shape[1] let c = Tensor.zeros([m, n], DType.float64) for i in range(m): for j in range(n): for p in range(k): c[i, j] += a[i, p] * b[p, j] return c
看着是不是很像 Python？缩进、for 循环、range——几乎一样的写法。Mojo 编译器在编译阶段就把类型定死了，把循环展开、向量化，最终生成直接跑在 CPU 上的机器码。08 跑分说话：到底快多少？
这里要先把话说清楚：下面所有的加速比，对比的都是"纯 Python 循环"，不是 NumPy。在矩阵乘法这种 BLAS 已经高度优化的场景里，Mojo 和 NumPy 是在同一量级的，甚至可能不如 NumPy（因为 OpenBLAS 已经优化了十几年）。Mojo 真正的价值，是在那些"没有现成 C 库可调用"的自定义计算逻辑上。一份公开的基准测试（Apple M4 Pro 芯片，对比纯 Python 实现）显示：在 Mandelbrot 集计算这种纯循环密集型任务中，Mojo 甚至达到了21,948 倍的加速。什么概念？你那个跑 20 分钟的纯 Python 数据处理脚本，用 Mojo 重写核心循环后，可能只要 1 秒不到。09 混合开发的逻辑——各司其职
第一步：在 Mojo 里写好计算函数，通过模块构建器编译为共享库。第二步：在 Python 代码里调用编译好的 Mojo 模块。Python 代码里调用 Mojo 编译的模块import my_mojo_module# 调用 Mojo 写的高性能函数result = my_mojo_module.fast_compute(large_dataset)
这套东西的逻辑就是Python 做胶水，Mojo 做引擎：Python 负责 I/O：Web 路由、数据库读写、爬虫抓取、业务流程Mojo 负责计算：自定义数据处理、数值计算、CPU 密集的循环、需要指针直接操作内存的场景你不需要把所有代码都改成 Mojo。只需要把最慢的那 5% 的热点函数用 Mojo 重写，就能获得 95% 的性能提升。另外提一句：Mojo 的编译器和工具链虽然开源了，但目前尚未接受外部对编译器本身的代码贡献（预计 2026 年底开放）。如果你想参与开源，可以先从周边工具和文档入手。最后
有人说 Python 慢、Python 只能调包、学 Python 没前途。我的感受是：Python 从来不是为裸算力而生的语言。它在 I/O 密集、快速迭代、连接生态的场景里，是当之无愧的王者。而 Mojo 的出现，正好补上了 Python 在算力上的短板——但它补的不是 NumPy 的位，而是"纯 Python 循环"的位。Python 做胶水，Mojo 做引擎。各司其职，各取所长。作为一个纯爱好的编程学习者，这种感觉挺有意思的——看着技术一点点往前走，手里的工具越来越顺手。"每一个程序员必须要走的一条路，一定要坚持住。你正在进入编程的深水区，要坚持住。程序员遇到困难一定要走出去，一直保持学习的心态。"
从那个凌晨三点的 PyQt5 爬虫，到现在研究 Mojo 的指针和编译器——我走了很远，但也知道，深水区从来不是靠躲过去的，是一步步蹚过去的。你们觉得 Python 和 Mojo 这个组合怎么样？评论区聊聊。
本文参考了 Mojo 1.0 开源公告、Cemrehan Çavdar 公开基准测试及 Mojo 官方文档。觉得有用？点个在看，转发给那个还在用 Python 写死循环的朋友。让他知道——不是 Python 不行，是你没给它找对帮手。
10个月宝宝每天需要喝多少奶粉？
