为什么我选择了 Python

「学第一门语言该选什么」这个问题我被问过很多次，我的回答一直没变：Python。但每次说完我都要补一句——不是因为它最强，而是因为它最不挡我的路。这两句话差别很大，前者是技术判断，后者是个人取舍。这篇把我的取舍过程完整摊开：我试过什么、为什么最后留下它、以及哪些情况我根本不建议你用。

一、先说结论

我从头到尾只想做成两件事：把脑子里的想法快速变成能跑的东西，以及把重复的活交给机器。这两件事的共同要求是"从想法到结果的路径要短"。Python 在这条路径上，几乎是所有主流语言里最短的。这就是全部理由。

二、我当年试过哪些

我不是一开始就认准 Python 的。早期我什么都碰了一点，说出来你可能也有同感：

• 先是 C 语言。学校里学的。指针、内存、编译错误，光是让程序跑起来就要折腾半个下午。学到后面我确实理解了内存是怎么一回事，但那个阶段我想做的是"完成一个小东西"，不是"理解计算机原理"。用的方式和目标不匹配。
• 然后是 Java。写一个最简单的东西，要先理解类、包、构建、一堆目录约定。它的工程化程度很成熟，但那份成熟是给几百人协作准备的，而那时候我只有自己一个人。给我一把工业级的扳手去拧一颗小螺丝，重。
• 也试过前端那套。上手是真的快，改一行刷一下就有效果，那种即时反馈很上瘾。但它主要解决的是"界面"这个问题。一旦我想处理文件、跑点数据、做点后台的自动化，就得再找别的路子。
• 最后回到 Python。原因是有一天我写了个二十行的脚本，把一个我本来要手动做四十分钟的活，一秒钟做完了。那天之后我就没再换过。

三、Python 到底赢在哪

上面那段经历只是结果，我还想过为什么是它。总结下来是五条，每条我都拿别的语言对照过：

1. 从想法到能跑，中间几乎没距离

不用声明类型、不用编译、不用管构建配置。写完一个文件，敲一行命令就跑。这个看起来是小事，实际影响巨大：反馈周期越短，你试错的速度越快，学得越快。

# 这就是一个完整的、能跑的程序，没有任何多余的东西
with open("notes.txt", "r", encoding="utf-8") as f:
    lines = f.readlines()
print(f"一共 {len(lines)} 行")

# 对比一下，同样的事在有些语言里的样子（示意）
#include <stdio.h>
#include <stdlib.h>
int main(void) {
    FILE *fp = fopen("notes.txt", "r");
    if (!fp) { perror("open"); return 1; }
    int lines = 0, ch;
    while ((ch = fgetc(fp)) != EOF) if (ch == '\n') lines++;
    fclose(fp);
    printf("一共 %d 行\n", lines);
    return 0;
}

两边都能跑、结果一样。但一个是"我想读个文件"，另一个是"我要先跟文件句柄、错误码、内存打交道，顺便读个文件"。差别不在难易，在注意力被占掉了多少。

2. 需要什么，基本都已经有人写好了

这是它最实际的优势。处理表格、生成文档、算数据、画图、批量改文件、调各种网络资源——你想到的事情，几乎都有现成的库可以直接用，装一下、导入、用。你不需要自己从零实现，只需要正确地把它们拼起来。

我一开始还觉得"用别人的库"有点不好意思，像作弊。后来想通了：我的目标是把事情做成，不是把轮子重新发明一遍。能站在别人的成果上往前一步，这本身就是效率。

3. 它逼我思考的是问题本身

有些语言的难点在语言本身：类型系统、内存管理、编译过程，你要先花很久跨过这些，才能开始解决真正的问题。Python 把这些基本藏起来了，于是我被逼着面对的只剩三个问题：输入是什么、输出是什么、中间怎么变。

这三个问题才是真正的难点，也才是真正值得花时间的地方。我更愿意把学习时间用在这上面，而不是用在跟编译器较劲上。

4. 写得越久，越能体会到"读得懂"的价值

三个月后回头看自己写的脚本，很多语言里你要费点劲才想起"当时为什么这么写"。Python 的语法接近自然语言，缩进代替括号，大部分代码不需要注释也能读懂它在干嘛。这一点在偶尔才维护一次的小脚本上尤其重要——因为它们没有文档、没有测试，全靠你自己看懂。

5. 它能从小长到大

最后这条我一开始没意识到，后来才发现很关键：Python 的脚本可以只是二十行的自动化，也可以长成一个正经的后台程序，中间不需要"换语言重写"。一个东西从"我随手写的"变成"我天天在用的"，它可以一直用同一套东西演进下去。不用因为规模变大就推倒重来，这对个人项目来说是巨大的省事。

四、它的短板我不回避

如果只说优点，那就是软文不是笔记了。Python 的问题非常明确，我列在这，并且说清楚我自己怎么处理的：

逐条说我的应对：

• 慢怎么办？先问一句：这个慢会不会影响结果？我的场景大多是"处理一批文件"或"响应一个请求"，瓶颈通常在磁盘、网络、或者算法写得不好，而不是语言本身。把算法改对，比换语言省事一百倍。
• 并发怎么办？先分清是"等的时间多"还是"算的时间多"。等的时间多（网络、磁盘）用异步或线程池就能大幅改善；算的时间多，就把那一小块单独拆出去，用更合适的语言写，剩下的还是 Python。不必为了 5% 的环节把 95% 的代码重写一遍。
• 可读性在大项目里失控怎么办？这是真问题，也是所有灵活语言的通病。我的做法是靠纪律而不是靠语言：命名写清楚、函数别写太长、类型标注能写就写。语言不会替你做架构决定。

五、什么情况我不建议用 Python

这个section其实比"推荐"更重要。以下几种场景，我会明确建议换别的：

• 要做手机上的原生程序。这不是它的战场，硬上会一直别扭。
• 性能就是产品的核心指标。比如对延迟或吞吐有非常苛刻的要求，编译型语言在起点上就有优势。
• 要交付给不懂技术的用户一个双击就能跑的东西。不是做不到，只是要额外处理发布的问题，比写代码本身还费劲。
• 团队已经有一个成熟的技术栈。统一比"最合适"重要。为了爱好分裂技术栈，长期成本会远超收益。

六、那条学习曲线

最后放一张我自己感受最深的图。同样是"想做出东西"这个愿望，不同语言让你尝到甜头的时间点差别很大：

我想说的不是"简单就是好"。曲线平缓意味着你更容易坚持下来，而坚持这件事，在学任何东西上都是最大的变量。很多人放弃编程，不是因为难，而是因为连续几周都做不出任何能看见的东西。Python 最大的贡献，是让"做出东西"这件事来得足够早。