Python 1200 期特辑——写了 1200 篇技术文章，我对 Python 的真实看法
Python 1200 期特辑——写了 1200 篇技术文章，我对 Python 的真实看法
适读人群：所有关注「老张聊AI转型」的读者，无论你是 Python 新手、老手，还是在考虑要不要学 Python 的工程师 | 阅读时长：约18分钟 | 核心价值：1200 篇之后，一个写了多年 Python 的 Java 工程师，对这门语言说最真实的话
今天是第 1200 篇。
坐在电脑前，我打开了一个新的文档，准备开始写，但光标在那里闪了很久，我没有动。
1200 这个数字是什么概念？如果你每天更新，那是将近 3 年半。如果你每周三更，那是将近 8 年。我是中间某个频率，不算规律，但从没间断。
一开始写这个公众号，只是想记录自己从 Java 转到用 Python 做 AI 的过程，没想到会有这么多人在看，也没想到自己真的能写到第 1200 篇。
很多读者私信我问过各种各样的问题，但问得最多的一类是：老张，你觉得 Python 到底怎么样？值得学吗？
今天这篇，我想给出我最真实的答案。不是为了流量，不是为了说 Python 有多好，而是说我真正的看法——包括那些我认为很多人不愿意说、或者没有资格说的话。
我和 Python 的关系，是从排斥开始的
2018年，我在一家做企业软件的公司，写了五年 Java。Spring Boot、Hibernate、Kafka，一套流程走下来行云流水，我对那套体系非常熟悉，也很自信。
那年公司开始做一个推荐系统，数据科学家们都在用 Python。有一天我需要调试一个数据处理脚本，环境没装好，Python 版本冲突，pip 报错，虚拟环境乱掉了，折腾了整整一个下午，最后发现是 Python 2 和 Python 3 的 pip 混用问题。
我当时心里只有一个想法：这什么破语言，连包管理都搞不明白。
然后我继续写我的 Java。
这种状态维持了大概半年。直到我参与了一个 NLP 项目，不得不用 Python，才开始认真学。
Python 确实有它无法辩驳的优势
学了半年，我必须承认，Python 在某些地方确实比 Java 好，不是因为"语法更优雅"这种虚的，而是有具体的、实实在在的理由。
第一：AI/ML 生态是唯一的，不可替代。
PyTorch、TensorFlow、scikit-learn、Hugging Face——这些库根本没有在其他语言里可比较的替代品。你不是选择用 Python，你是因为用这些库所以用 Python。这是现实，不是偏好。
我见过有人说"Java 也能做 AI"，技术上不是不行，但你要用 DJL（Deep Java Library）调 PyTorch 模型，其实还是在用 Python 生态的成果，只是套了一层 Java 皮。
第二：快速验证想法，Python 的生产力是真实的。
同样的一个数据处理逻辑，我用 Python 写，大概3分钟。用 Java 写，包括写 DTO、写 Service、写 Repository，至少要15分钟。
这不是说 Java 不好，Java 的严格性在大型工程里有它的价值。但在"我有一个想法，想快速验证它"这个场景下，Python 的速度优势是碾压级的。
在 AI 工程里，我们经常需要快速实验：换一个 embedding 模型试试效果、调整 prompt 看看结果、换一种分块策略对比 RAG 质量——这种"验证驱动的开发"模式里，Python 的速度优势每天都在帮我节省时间。
第三：脚本类工作，Python 是最合适的工具。
数据迁移脚本、日志分析脚本、批量文件处理脚本——这类工作用 Python 写简洁、直接、容易维护。放着这么好用的工具不用，去写一个 Java main 函数处理这些，是在给自己找麻烦。
但是，Python 真的没有你想象的那么适合所有 AI 项目
这是我想说的最重要的一句话，也是我认为业界最普遍的一个误区。
Python 适合做 AI 项目的研究、原型、数据处理和模型推理接口层。但它不适合做 AI 项目里所有的东西。
具体来说：
高并发 API 服务，Python 不是最好的选择。
GIL（全局解释器锁）是一个绕不开的话题。Python 多线程在 CPU 密集型场景下基本没有并行加速，多进程虽然能绕开 GIL，但进程间通信开销大，内存占用也高。
是的，我知道有 asyncio，我知道异步 IO 可以处理高并发。但并发和并行是两件事。异步处理的是"等待"，不是"计算"。如果你的 AI 接口需要做大量 CPU 计算（比如实时推理），Python 的 worker 并行能力是有限的。
同样的服务，用 Java 或者 Go，通常能在同样的硬件上跑出更高的吞吐量，用更少的内存。这不是 Python 的问题，这是 Python 的设计决策带来的代价，是正常的 trade-off。
大型工程项目，Python 的动态类型是双刃剑。
Python 的动态类型让你写代码很快，但让你维护代码库很痛苦。一个没有类型注解、没有严格检查的 Python 项目，到了几十万行代码的规模，重构是噩梦。
我们花了很大力气推 mypy + type hints，效果是好的，但这在本质上是在给 Python 补上它原本没有的特性。Java 是生来就有严格类型的，Python 是后来打补丁的——这两种在大型项目维护上的差距，工作3年以上的工程师应该都有体感。
Python 的运行时性能，在某些计算密集型场景是真实的瓶颈。
NumPy、PyTorch 这些库底层是 C/C++ 写的，所以才快。但你自己写的纯 Python 循环，可以比 Java 慢 10~50 倍。我写过一个图算法，Python 实现跑了 47 秒，用 numpy 向量化之后 0.3 秒，后来改成 C 扩展（Cython）是 0.08 秒。
Python 的高性能代码，经常需要你"换一种不太像 Python 的写法"——向量化、C 扩展、Numba JIT……这些技巧要学，代价是代码变得不那么直观。
我踩过的三个关于 Python 的认知坑
坑一：以为学了 Python 就能做 AI
刚开始转型的时候，我以为只要学会 Python 语法，学会 PyTorch，就能做 AI 了。学了两个月，发现自己写出来的模型训练代码跑不起来，因为根本不懂数学：梯度是什么、反向传播是怎么工作的、损失函数为什么要这样设计。
Python 只是工具，AI 是问题领域。 学 Python 不等于学 AI，就像学会开车不等于你懂赛车工程一样。
我花了额外的6个月补了线性代数、微积分、概率统计的基础，才觉得自己开始真正能理解在干什么，而不只是"调包工程师"。这6个月是我这几年最值的投资。
坑二：以为 Python 的简洁意味着代码质量自然好
Python 写起来简单，这让很多人误以为 Python 项目天然就好维护。这是错的。
我见过比任何语言都乱的 Python 代码——全局变量满天飞，函数几百行，根本没有任何模块化设计，类型注解一行没有，测试代码不存在。
任何语言都可以写出糟糕的代码。Python 的简洁只是降低了入门门槛，不能替代工程设计能力。
好的 Python 代码需要刻意的工程化：类型注解、模块化设计、测试覆盖、代码 review。这些努力和写 Java 是一样多的，甚至因为语言本身不强制，需要更多的自律。
坑三：以为 Python 的包管理"就是这样"，接受就好了
pip、virtualenv、conda、poetry、pipenv、uv——Python 的包管理工具混乱程度是出了名的。我花了将近一年才找到自己觉得最顺手的方案（现在用 uv + pyproject.toml）。
这个问题我觉得 Python 社区不应该被洗地。npm 在 2015 年就已经有了 package-lock.json，Java 有 Maven/Gradle，Go 有 go.mod。Python 在依赖管理上落后了太多年，虽然近两年 uv 的出现终于让情况好多了，但历史遗留的混乱还在。
如果有人告诉你"Python 的包管理就是这样，习惯就好了"，这是不正确的认知——这是一个需要改进的问题，不是一个需要接受的现实。
心态的变化
现在，如果让我重新描述我对 Python 的态度：
我尊重 Python，但不崇拜它。
它是我日常工作中使用频率最高的语言，没有之一。我靠它做了很多有价值的东西，帮了很多人，也让自己在 AI 时代找到了定位。
但我也同时保持着对它缺点的清醒认识。我不会因为我是"Python 工程师"就无条件维护这门语言，也不会因为有人批评 Python 就觉得受到了冒犯。
语言是工具。好的工具人会根据场景选工具，而不是一辈子只爱一把锤子。
我对"要不要学 Python"的真实建议：
如果你想做 AI/ML，学，没有选择。这个领域你绕不开 Python。
如果你是 Java/Go/Rust 工程师，想了解 Python：用两周时间学基础语法，然后针对你工作中的具体场景找一两个最相关的库练手。不需要放弃你原来的语言，Python 做数据处理和脚本，Java/Go 做高并发服务，双语言是很多优秀工程师的选择。
如果你把 Python 当成"学了就能找到好工作"的敲门砖：Python 的门槛很低，这意味着初级 Python 工程师的竞争极其激烈。真正有竞争力的是"用 Python 解决了什么复杂问题"，而不是"会写 Python"。
写到这里，说点私人的话
1200 篇，这个数字背后是 1200 个晚上，或者 1200 个周末上午，或者 1200 段地铁通勤时想出来的思路。
我不是每一篇都写得好，有些篇幅写得很水，回头看会不满意。但我每一篇都是在认真想"这件事我真正理解了吗，能不能讲清楚"，而不是为了凑数。
最让我高兴的不是阅读量，是那些评论区里说"老张这篇帮我解决了一个困扰了我两周的问题"。每次看到这种评论，我都觉得值了。
评论区里也有很多争论。有人说我的某个观点是错的，我会认真看，如果他说得有道理，我会在后续文章里改正。有人说我的代码写得不好，我会去研究为什么他觉得不好。这些争论是我进步最快的来源。
接下来的方向
1200 之后，我想继续写。但方向会有一些调整：
更多"做出来"而不是"讲清楚"。 我想多写一些完整的项目案例，从需求到代码到上线，完整的全过程，而不是只讲某个技术点。
更多关于 AI 工程化的真实坑。 AI 应用工程化目前还是一个相对年轻的领域，踩坑的人比有经验的人多得多。我想把我踩过的、见过的坑写出来，帮后来的人少走弯路。
更多和读者互动产生的内容。 很多好文章的想法是来自读者的问题，我想保持这种互动。
谢谢你读到这里。
谢谢每一个看过我某篇文章、因为觉得有用而关注的读者。
谢谢每一个在评论区认真反驳过我、让我改进了某个观点的人。
继续写，继续学，继续分享。
到 2000 篇的时候，我们再见。