7 种语言 / 框架，渲染同一个博客页 —— Python 到底慢不慢？

结论先行（TL;DR）

01起因与测试方法

这个站的博客基于 FastAPI + Jinja2，JSON 文件存数据，生产上跑得好好的。直到我做了一次裸压测——把响应缓存旁路掉、只测“纯渲染”这一段，博客列表页只有 88 RPS / 单次 11.3ms。一个十篇文章的列表页，模板渲染怎么会要 11ms？是 Jinja2 慢？Python 慢？还是 FastAPI 这套异步框架的锅？与其猜，不如把同一个页面用别的语言各写一遍，让数字说话。

对照原则

所有实现读同一份 meta.json（592 篇文章元数据），渲染同一套模板结构，只读不写（写仍由生产 FastAPI 承担），保证比的是“渲染 + HTTP 这条路径”本身。

环境与单核绑定

腾讯云单台 2 vCPU（Xeon 8255C @ 2.50GHz）/ Ubuntu 24.04。施压机与被测机走内网，排除公网带宽干扰。所有副本用 taskset -c 0 在启动时绑到单核——这点关键：Go 的 GOMAXPROCS、.NET 的线程池都在进程初始化时读核数，必须启动即绑核，否则它们按 2 核初始化、再被限到单核运行，会因线程争抢得出失真数据（本文初版就因 .NET 副本漏绑核，把双核的 ~1043 误当单核，后已订正为 422）。

两组对照

A 组反映“生产实际表现”（绝大多数请求命中缓存），B 组反映“应用裸上限”（缓存失效 / 首次访问的成本）。压测工具 ApacheBench（keep-alive），QPS 取多并发档位平均（非峰值）。下文数字均为 2026-06-21 单核公平复测值。

02第一战：裸渲染横向对比

先看 B 组——每个请求都真渲染，最能暴露引擎和业务逻辑的真实成本。单位 RPS，越长越快：

03元凶：auto_excerpt 的重复 IO

同样是 Jinja2，干净实现能到 900+ RPS，优化前的生产却只有 88。差距藏在列表页的“摘要生成”里。下面是优化前的真实代码逻辑（app/services/blog_renderer.py）：

# 优化前：渲染列表页时，每篇文章都重算摘要
def _enrich_post(post, ..., auto_summary=True):   # ← 列表 context 传了 True
    if auto_summary:
        out["summary"] = _auto_excerpt(post["id"])   # 每篇都重算

def _auto_excerpt(post_id):
    html = open(f"{post_id}.html").read(8192)              # ① 读文件
    text = BeautifulSoup(html, "html.parser").get_text()   # ② 解析 HTML
    return text[:50] + "…"                              # ③ 截断 50 字

# 列表 page_size=10  →  每请求 = 10 次文件读 + 10 次 BeautifulSoup 解析
# 而 meta.json 里，每篇文章其实早就存好了 summary 字段……

也就是说：服务器每渲染一次列表页，就把 10 篇文章的正文从磁盘读出来、用 BeautifulSoup 解析一遍 HTML、再截取摘要——而这个摘要本就已经存在 meta.json 里。一段纯粹的重复劳动，且 BeautifulSoup 解析是 CPU 密集的。

修复很简单：把摘要生成挪到写入侧。抽出纯函数 generate_summary(html)，在上传 / 编辑文章时生成、固化进 meta.json（存量文章启动时一次性迁移回填）；渲染侧 _enrich_post() 不再传 auto_summary（默认 False），直接读 meta.summary——零文件 IO、零解析。

04第二战：cache 命中对比

再看 A 组——命中响应缓存。这里要先说清缓存层是怎么工作的（app/core/cache_middleware.py）：HTML 响应按 Accept-Encoding 预压缩成 gzip / identity 两个内存桶，命中时直接吐对应桶的字节流 + ETag——命中路径零渲染、零压缩、零拷贝。所以 A 组测的不是渲染，而是“缓存层 + HTTP 栈”每秒能吐多少个预压缩响应：

Node fastify、Go 在极轻的 HTTP 栈上领先；Python 用 socketify 也追到 4121，跟它们同档。但真正值得说的，是 Python 这条线从 生产的 1567 一路爬到 4121 是怎么做到的——而且这一段全程不涉及渲染（命中根本不渲染）。

05cache 优化阶梯：1567 → 4121

命中既然不渲染，瓶颈就只能在“接到请求 → 吐出缓存字节”这条 HTTP 路径的每请求开销上。同样的 Python、同样的缓存逻辑，只改“外围”，逐层剥掉 overhead：

① Py3.14 + uvloop + 砍掉审计中间件（→ 2210，+41%）

两个免费提升：CPython 3.12 升到 3.14（+10%）、事件循环 asyncio 换成 uvloop（+6%，uvicorn --loop auto 装了就自动启用、不改一行代码）。再砍掉生产那层审计采集开销，到 2210。

② 去掉 FastAPI / Starlette 框架层（→ 3155，+43%）

生产每个请求要穿过两层 BaseHTTPMiddleware（custom_middleware + cache_middleware，见 server.py）。而 BaseHTTPMiddleware 为每个请求开一个 anyio task group + 构造一个完整的 Request 对象——缓存命中时这些全用不上。手写最薄的 ASGI、命中直接 send 预压缩字节，省掉这些每请求开销，+43%。这印证了：cache 命中的瓶颈从来不是渲染，而是框架对象的创建成本。

③ 把 HTTP 层换成 uWebSockets（→ 4121，+31%）

socketify.py 基于 C++ 的 uWebSockets，绕过 uvicorn / ASGI，HTTP 解析全压进 C++，Python 只管业务，再 +31%。代价是 0.x 库、生态不成熟——这一步是“能到多高”的探底，不适合上生产。

06多核扩展性：谁能吃满第二个核

生产机是 2 vCPU，所以还有一个关键维度：把裸渲染从单核放开到双核，各栈能不能用上第二个核？差异巨大，直接决定选型：

.NET / Go 的多线程运行时能并行吃满两个核，Python（GIL）和 Node（单线程事件循环）锁死单核。所以 2 vCPU 上单论裸渲染峰值，编译型多线程栈确实能比 Python 高一截——但这只影响缓存失效（MISS）路径。生产绝大多数请求命中缓存（不渲染），所以这个优势在真实流量下几乎用不上。

注：本文初版曾把 .NET 的双核值（~1043，未绑核误测）当成单核数据列在裸渲染榜，导致 .NET 看起来排第 4。绑核重测后单核真值是 422，已全文订正。

07落地：优化前后对比（生产实测）

探底归探底，真正搬上生产的只有“零风险纯收益”这批：删 auto_excerpt 重复 IO + 固化 uvloop / httptools。生产单核裸渲染的实测前后对比：

* cache 命中走预压缩内存桶、不经渲染，删 auto_excerpt 只作用于裸渲染路径，cache 持平属预期——优化打在了刀刃上。

为什么生产是 536，而不是 §05 说的 ~870？因为生产带着完整中间件栈（两层 BaseHTTPMiddleware + 审计 + Request 对象），那 ~870 是 FastAPI lite 精简栈的数。这 536 → ~870 的缺口要靠把中间件改写成 pure ASGI 才能补，跟“换语言”无关——而且只惠及罕见的缓存失效路径，性价比远不如直接给缓存命中那条路加一层极薄的 ASGI fast-path（可把命中从 1567 提到 ~2800）。

08结论

把这台 2 核小机器上的数字摆齐，故事很清楚：

• Jinja2 裸渲染 0.87ms / 1154 RPS 全场最快，快过 Go gonja、.NET Scriban、Node nunjucks。模板引擎不是 Python 的短板。
• 生产那个 88 RPS 的“慢”，100% 是 auto_excerpt 的重复 IO——每请求 10 次文件读 + 10 次 BeautifulSoup，一删就回到 536（6.1×）。
• 缓存命中的吞吐瓶颈在框架 / HTTP 栈的每请求开销（两层 BaseHTTPMiddleware 的 task group + Request 对象），不在渲染——去框架 +43%，换 uWebSockets 再 +31%。
• 2 vCPU 上只有 .NET / Go 能并行吃满双核；但生产主路径是缓存命中（不渲染），这个优势用不上。

“Python 慢” 在这个场景里是个伪命题。慢的从来不是语言，是架构里那些不必要的工作。把它们找出来删掉，Python 一样能打。真正值得落地的是“删 auto_excerpt + uvloop”这类零风险优化（已上生产，6.1×）；性能探底（socketify 4121）是为了看清天花板，不等于都要搬上生产。

09附录：完整数据

2026-06-21 单核公平复测（taskset -c 0 启动绑核）。QPS 为多并发档位平均值（A 组 c=10/50/100/200，B 组 c=10/20/50），ApacheBench keep-alive，内网。

裸渲染（B 组，单核）

Python 版本细分（Jinja2 裸渲染）：3.12·asyncio 821 → 3.12·uvloop 870 → 3.14·asyncio 902 → 3.14·uvloop 953。3.14 与 uvloop 各贡献约一档。

cache 命中（A 组，单核）

cache 命中不经渲染，删 auto_excerpt 对其无影响，故生产优化前后均为 ~1570（复测 1567 / 部署后 1594，差异在运行间波动内）。Go / 裸 ASGI 在高并发档偶发连接重置，取有效档位均值。

多核扩展性（裸渲染，单核 → 双核）

优化量化（区分裸渲染 vs cache 命中两条路径）