程序员要会几种语言

```html

“你会几种语言？程序”——面试时被问到这个问题，我差点脱口而出“中文和英文”。种语对面坐着的程序是个技术总监，他笑着补了一句：“我说的种语是编程语言。”气氛稍微松了松，程序但我还是种语得老实回答：常用的三四种，能写的程序不超过六种，剩下的种语都是“看过文档，写过demo，程序没上过生产”。种语他点点头，程序说他自己也差不多，种语简历上列了十几种，程序真正敢在项目里用的种语，一只手数得过来。程序

这不是谦虚。我见过一个写了十五年Java的老哥，被拉去救一个Python的数据管道项目。他花了两天把语法过了一遍，第三天开始改代码，第四天就提交了PR。但review的时候，另一个同事指着一段用pandas做分组聚合的代码说：“你这里用groupby加apply，数据量一大就慢，为什么不直接用transform？”老哥愣了一下，说Java里没这概念，他以为能跑通就行。这就是“会”和“会用”的差距。语言本身的语法可能一周就熟了，但那个语言生态里的惯用法、性能陷阱、工具链，得靠时间喂出来。

所以到底要会几种？我的观察是：两门深的，三门能改的，外加一堆能看懂的。深的这两门，最好跨越范式。比如一门静态类型、编译型的（Java/Go/C++），一门动态类型、脚本型的（Python/Ruby/JS）。这样你在面对新问题时，脑子里会有两套不同的解题路径。我自己的组合是Java和Python。写后端服务用Java，因为类型系统能帮我在编译期挡掉一堆低级错误；写运维脚本、做数据清洗、搭原型用Python，因为快，不用写一堆样板代码。这两门语言我敢在简历上写“精通”，因为踩过的坑够多——Java的并发包我读过源码，Python的GIL我吃过亏。

能改的三门，通常是跟着项目走的。比如你突然被拉去写前端，总得会JavaScript或者TypeScript；公司用Go重构微服务，你得能看懂goroutine和channel；偶尔要改个C++的底层库，至少得知道指针和引用怎么用。这些语言不需要你从零设计架构，但给你一个现有模块，你得能加功能、修bug。我有个同事，之前只写C#，后来公司买了套Ruby on Rails的老系统，他硬着头皮看了两周，现在也能改改路由和模型了。他说：“语法怪是怪，但逻辑都差不多。”

至于“能看懂的”，那就多了。Shell、SQL、HTML/CSS、甚至汇编。你不一定要写，但看到一段代码得知道它在干嘛。有一次线上事故，日志里混了一段Lua脚本报错，团队里没人会Lua，最后是一个平时爱折腾Nginx的哥们儿看出来的——他之前配过OpenResty，勉强能读。这种“边缘语言”不一定天天用，但关键时候能救命。

别被“语言数量”绑架。我见过简历上写“精通C++、Java、Python、Go、Rust、Haskell”的候选人，面试时连Go的slice和数组的区别都说不清。面试官不傻，你写“了解”和写“精通”，问的问题深度完全不一样。与其堆砌名词，不如把两门语言吃透，剩下的诚实标注“熟悉”或“用过”。

还有个反直觉的点：语言之间的迁移成本，比你想象的低。你学会了Java的Stream，再看Kotlin的集合操作，十分钟就能上手；你搞懂了Python的装饰器，再去看TypeScript的装饰器，概念是通的。真正难迁移的是思维模式——比如从面向对象转到函数式，从手动内存管理转到GC，从同步阻塞转到异步非阻塞。这些跨越了语言边界，但一旦掌握，你学新语言就是“换皮”而已。

最后说个真事。我认识一个写了二十年C的程序员，他只会C和一点汇编。但公司里所有性能瓶颈的活儿都找他。他不懂Python，不懂Java，可他能把一段C代码优化到极致，让上层语言调用。你说他该会几种语言？一种，但这一种深到别人替代不了。所以别纠结数量，纠结你手里那把锤子，能不能砸开面前这颗钉子。