「我們公司用 Node.js，我只要精通 Node.js 就夠了吧？」
這個邏輯十年前是對的。你在一個用 PHP 的公司工作，PHP 就是你的全部。那個年代，後端服務通常是一個大型的單體應用，同一個語言寫到底。
現在不一樣了。
你不會只碰一種語言的四個場景
場景一：你的服務不是孤島
微服務盛行之後，一個中型產品可能長這樣：
- 主業務邏輯：Node.js
- 付款處理：Java（穩定、有成熟的金融套件）
- ML 推薦服務：Python（沒得選，PyTorch 就是 Python）
- 高效能資料處理：Go
你的 Node.js 服務會和其他三個語言的服務互相呼叫。當付款服務出問題，你能看懂那個 Java 的 stack trace 嗎？能讀懂 Go 服務的 log 嗎？如果不行，你只能等別人來解釋，然後等別人修。
場景二：你依賴的 OSS 不是你選的語言
你用 Node.js，但你在用：
nginx（C）PostgreSQL（C）Redis（C）Kafka（Scala/Java）Prometheus（Go）
這些是你服務的基礎設施。當 Redis 出現奇怪行為，你看到的 issue 討論和原始碼是 C。當 Kafka consumer lag 突然飆高，你要讀的是 Scala 的配置說明和 Java 的客戶端文件。
你不需要能寫 Scala，但你需要能讀懂它在說什麼。
場景三：debug 不等人
生產環境凌晨三點炸了。這個 bug 在 Python 的 ML 服務裡。你們 Python 的工程師在休假。
你看得懂 Python 的 traceback 嗎？你能在 Python 環境裡跑一個測試確認假設嗎？你能至少看懂問題出在哪、能不能 rollback？
連 traceback 都看不懂，你在那個當下什麼都做不了——不是叫你去精通 Python，是說這個最低門檻是真實存在的。
場景四：面試和跨團隊對話
「這個設計我們在 Java 那邊也有類似實作，它用 CompletableFuture 解的。」
能接上這句話，代表你知道 CompletableFuture 大概是什麼、跟你熟悉的 Promise 是同一類東西。不能接上，這個設計討論你只能在旁邊聽，很難貢獻。
所以要精通幾種語言？
不是精通，是有足夠的模型認識。
「能看懂、能改、能 debug 基本問題」和「精通這個語言的所有慣用法和生態系」是完全不同的目標。前者要的是模型理解，後者要的是大量實踐和記憶。
你正在用的語言，才需要精通。
其他語言，需要的是：看到 goroutine 知道那是並行 primitive、看到 Result<T, E> 知道那是錯誤處理的 return 方式、看到 @Bean 知道那是 DI 的宣告。這個程度，靠的是模型，不是語法記憶。
這就是為什麼理解跨語言共通概念比背第二種語言的語法更有投資報酬率。
「模型認識」的意思不是「讀過文件」。是說你看到 goroutine 不需要查，看到 Result<T, E> 不需要查，能在閱讀和對話裡即時辨識。這個程度靠的是理解底層模型，不是把每個語言的語法背一遍。