在我們選擇用哪種編程語言進行後端開發的時候，Python 和 Go 似乎代表了兩種極端：

Python 以人生苦短我用Python的開發效率聞名，卻經常因性能被調侃為慢如龜速；

Go 則以編譯即部署的輕量和高併發性能成為雲原生時代的寵兒，卻因語法簡陋被吐槽開發像搬磚。

而 PyPy 的出現，像給 Python 注射了一劑強心針，這個基於 JIT（即時編譯）的 Python 解釋器，宣稱能讓 Python 代碼運行速度提升 5-10 倍。於是我們難免好奇：有了 PyPy，Python 能在後端開發中追上甚至超越 Go 的性能嗎？

今天就用 3 個後端核心場景（高併發 API、數據處理管道、長連接服務）的實測數據，結合底層原理和實戰案例，一次性説清這個問題。

後端開發的性能到底指什麼？

討論性能前，得先統一標準。對後端服務而言，性能從來不是單維度的誰跑得更快，而是以下三個核心指標的綜合：

• 吞吐量（QPS）：單位時間內能處理的請求數，直接決定服務承載能力；
• 延遲（P99/P999）：極端情況下的響應時間，影響用户體驗（比如支付接口的卡頓）；
• 資源效率：相同負載下的 CPU/內存佔用，直接關係服務器成本。

我們選擇的測試環境：

• 硬件：2 核 4G 雲服務器（模擬中小型後端服務的常見配置）；
• 語言版本：Python 3.11（CPython）、PyPy 7.3.11（對應 Python 3.9）、Go 1.21；
• 框架：Python 用 FastAPI（異步），Go 用 Gin（高性能框架）；
• 測試工具：wrk（壓測 HTTP 服務）、cProfile（Python 性能分析）、pprof（Go 性能分析）。

場景一：高併發 API 服務

後端最常見的場景：實現一個用户信息查詢API，接收用户 ID，從 Redis 查緩存，返回 JSON 結果。這是典型的 I/O 密集型任務。

代碼實現（核心邏輯）

# Python（FastAPI + asyncio + aioredis）
from fastapi import FastAPI
import aioredis
import json

app = FastAPI()
redis = None

@app.on_event("startup")
async def startup():
    global redis
    redis = await aioredis.from_url("redis://localhost")

@app.get("/user/{user_id}")
async def get_user(user_id: str):
    data = await redis.get(f"user:{user_id}")
    return json.loads(data) if data else {"error": "not found"}

// Go（Gin + redis/go-redis）
package main

import (
    "encoding/json"
    "github.com/gin-gonic/gin"
    "github.com/redis/go-redis/v9"
    "context"
)

var rdb *redis.Client
var ctx = context.Background()

func main() {
    rdb = redis.NewClient(&redis.Options{Addr: "localhost:6379"})
    r := gin.Default()
    r.GET("/user/:user_id", func(c *gin.Context) {
        userID := c.Param("user_id")
        data, err := rdb.Get(ctx, "user:"+userID).Bytes()
        if err != nil {
            c.JSON(404, gin.H{"error": "not found"})
            return
        }
        var res map[string]interface{}
        json.Unmarshal(data, &res)
        c.JSON(200, res)
    })
    r.Run(":8000")
}

壓測結果（100 併發用户，持續 60 秒）

關鍵結論：

1. PyPy 確實比 CPython 快：QPS 提升 50%，延遲降低 40%，但距離 Go 仍有 3 倍差距；
2. GIL 是 Python 繞不過的坎：即使 PyPy 用 JIT 加速了代碼執行，但 Python 的全局解釋器鎖（GIL）導致多線程無法真正並行，當併發超過 50 時，PyPy 的性能增長就會停滯，而 Go 的 goroutine 能輕鬆利用多核，QPS 隨併發數線性增長；
3. Go 的資源效率碾壓：相同 QPS 下，Go 的內存佔用僅為 PyPy 的 1/5，這意味着部署時 Go 服務能少用 4/5 的服務器。

場景二：數據處理管道（PyPy 最接近 Go 的領域）

後端另一個高頻場景：處理批量數據（比如解析日誌、清洗用户行為數據）。這屬於 CPU 密集型任務，也是 PyPy 的主場，JIT 編譯對循環、計算密集的代碼優化效果最明顯。

我們測試“解析 10 萬條 JSON 日誌（每條約 500B），提取關鍵字段並統計 UV（獨立用户數）”的任務。

代碼核心邏輯

# Python 版本（用 ujson 加速解析）
import ujson
from collections import defaultdict

def process_logs(logs):
    uv = defaultdict(int)
    for log in logs:
        data = ujson.loads(log)
        uv[data["user_id"]] += 1
    return len(uv)

# 讀取 10 萬條日誌並處理（省略文件讀取代碼）

// Go 版本（標準庫 encoding/json）
package main

import (
    "encoding/json"
    "os"
    "bufio"
    "strconv"
)

type Log struct {
    UserID string `json:"user_id"`
}

func processLogs(logs []string) int {
    uv := make(map[string]int)
    for _, log := range logs {
        var data Log
        json.Unmarshal([]byte(log), &data)
        uv[data.UserID]++
    }
    return len(uv)
}

// 讀取 10 萬條日誌並處理（省略文件讀取代碼）

執行結果（單進程處理時間）

關鍵結論：

1. PyPy 在 CPU 密集場景接近 Go：僅比 Go 慢 36%，這是兩者差距最小的場景；
2. Go 的靜態類型優勢顯現：Go 的 struct 解析 JSON 比 Python 的動態字典更快，且編譯期類型檢查避免了運行時類型錯誤；
3. PyPy 的侷限性：如果代碼中大量使用 C 擴展（比如用 pandas 處理數據），PyPy 會退化到 CPython 水平（因為 C 擴展繞過 JIT），而 Go 標準庫的純 Go 實現無此問題。

場景三：長連接服務

後端的硬骨頭場景：長連接服務（比如即時通訊、物聯網設備推送），需要同時維持 1 萬個以上的 TCP 連接，並實時處理消息。這類場景對併發調度和內存佔用要求極高。

我們測試“維持 1 萬連接，每 10 秒向每個連接推送一條 100B 消息”的服務表現。

核心實現差異

• Python（PyPy + asyncio）：用 asyncio 維護連接池，依賴事件循環處理 I/O，但每個連接仍需佔用一定內存（約 4-5KB）；
• Go：用 goroutine 綁定每個連接（每個 goroutine 初始棧僅 2KB），配合 channel 做消息分發，調度由內核級線程管理。

測試結果

關鍵結論：

1. PyPy 無法突破 Python 的併發模型瓶頸：即使 JIT 加速了單條消息處理，asyncio 的事件循環仍需在單線程內調度所有任務，高併發下會出現驚羣效應；
2. Go 的 goroutine 是降維打擊：輕量的協程+M:N 調度模型，讓 Go 能以極低的資源佔用維持海量連接，這也是 Go 成為雲原生網關、消息隊列（如 NSQ）首選語言的核心原因。

為什麼 PyPy 追不上 Go？

從測試數據看，PyPy 確實能讓 Python 在部分場景接近 Go，但始終無法全面超越，核心原因在三個層面：

1. 語言設計目標不同
   Python 從誕生就是開發者友好優先，動態類型、靈活語法帶來了開發效率，但也讓 JIT 優化難以做到極致（比如無法提前確定變量類型）；而 Go 是服務友好優先，靜態類型、極簡語法犧牲了部分開發便捷性，卻為編譯優化和併發調度掃清了障礙。
2. 併發模型的本質差異
   Python（包括 PyPy）的併發被 GIL 鎖死：同一時間只有一個線程執行 Python 字節碼，異步（asyncio）只是單線程內的任務切換，無法利用多核；而 Go 的 goroutine 是真正的並行，由 runtime 調度到不同內核線程，能充分發揮多核 CPU 性能。
3. 生態與部署的隱性成本
   PyPy 雖然兼容大部分純 Python 庫，但對 C 擴展（如 numpy、psycopg2）的支持很差，而後端開發常用的數據庫驅動、加密庫多依賴 C 擴展；反觀 Go，標準庫自帶電池，且編譯為單二進制文件，部署時無需依賴解釋器，這在容器化場景中優勢巨大。

什麼時候用 PyPy？什麼時候必須選 Go？

與其糾結誰更快，不如根據場景選工具：

一句話總結：PyPy 固然能優化性能，但只能讓 Python 在它的舒適區（中小流量、離線任務）跑得更快；而 Go 是後端性能的天花板，在高併發、資源敏感場景中，目前仍無替代者。

最後拋出一個問題：如果你的團隊正在用 Python 開發後端，且性能遇到瓶頸，你會選擇遷移到 PyPy 還是 重寫成 Go？ 歡迎在評論區分享你的經驗～

我是王中陽，靠敲代碼在北京買房的程序員，目前專注程序員的就業陪跑和職場晉升。有這方面需求可以聯繫我，聰明的你一定能想到辦法的。