Node.js HTML模板高并发渲染与压力测试指南

先说几个核心判断：EJS 渲染变慢，主要原因通常不是模板语言本身，而是缓存未开启、编译未复用、上下文传递不够合理。在 Node.js 服务端模板渲染场景中，真正的高并发瓶颈九成以上并非 HTML 字符串拼接，而是模板引擎实例的复用方式、缓存开关是否开启、上下文如何传递。如果直接使用 res.render() 接口进行压测，且日志未关闭、缓存未开启、编译结果未复用，那么测出的数据基本是假象。

为什么 EJS 渲染在并发下突然变慢？

EJS 的默认设置中，模板缓存是关闭的。这意味着每次调用 res.render()，它都会重新读取文件、解析 AST、生成函数——这一系列操作本质上是同步 I/O 加 CPU 编译，直接抵消了 Node.js 引以为傲的非阻塞优势。因此，以下几项措施必不可少：

• 显式开启缓存：app.set('view cache', true)（Express 在开发环境默认为 false，不要依赖其自动优化）
• 注意热重载工具（如 nodemon）触发的 fs.watch，它们可能导致缓存反复失效
• 模板中避免使用同步函数，如 JSON.parse()、fs.readFileSync()——这些操作会直接阻塞事件循环
• 检查 res.locals 中是否传入了一个巨大的对象，例如整张数据库表，序列化开销会随并发线性增长，严重影响性能

如何使用 k6 压测一个真实的 EJS 渲染接口？

k6 不能直接测试 HTML 渲染结果，它只负责发送 HTTP 请求。需要测试的是从请求进入至完整 HTML 返回的端到端延迟，因此后端路由必须真实调用 res.render()，同时排除静态资源干扰。可以换个思路：

• 编写一个专用测试路由，例如 GET /test-render，其中仅执行 res.render('dashboard', { user: { id: 1, name: 'test' } })，不查询数据库、不调用外部 API
• 在 k6 脚本中关闭默认的 cookie 自动管理（__ENV.K6_NO_COOKIES=1），避免 session 初始化拖慢首字节时间
• 使用 http.batch() 同时请求主页面和关键内联 JS/CSS（如果它们也走同一个 Express 渲染逻辑），模拟真实首屏加载链路
• 关键断言不是看状态码，而是关注 r.timings.duration < 80（P95 延迟）和 r.headers['content-type'] === 'text/html; charset=utf-8'

ab 或 autocannon 测出错误率飙升，先看哪几行日志？

不要急于调整参数。先确认是否是模板层的问题，而非连接被拒或超时。

• 查看 Node 进程的 stdout/stderr：出现 RangeError: Maximum call stack size exceeded → 模板递归渲染未设置深度限制
• 查看 Express 日志：大量 Cannot set headers after they are sent → 模板中使用了异步回调但未加 await，导致多次 res.send()
• 查看系统日志：dmesg | tail 检查是否 OOM killer 杀死了 Node 进程（EJS 编译阶段内存容易暴涨，尤其当携带大 JSON 数据时）
• 使用 node --inspect 启动，配合 Chrome DevTools 的 Memory 标签，对比压测前后的堆快照，确认是否出现了 CompiledFunction 实例泄漏——这是模板未复用的信号

pprof 火焰图里卡在 ejs.render() 内部，怎么办？

如果火焰图显示大量时间花在 String.prototype.replace 或 Function.constructor 上，说明在高频调用未缓存的模板编译逻辑。解决方案并不复杂：

• 先确认 app.get('view cache') 是否为 true，启动时打印一行 console.log('view cache:', app.get('view cache')) 进行验证
• 不要每次请求都 new 一个 ejs.Template()；改用 require('ejs').compile(templateString, { cache: true }) 做预编译，然后直接执行 compiledTemplate(data)
• 如果使用 Express，确保 app.engine('ejs', require('ejs').__express) 是官方绑定，而不是自己编写的封装——第三方封装容易绕过缓存机制
• 升级 EJS 到 v3.1.9 以上，老版本在多线程场景下，cache 键生成存在竞态，缓存 miss 率可能高达 40%

真正考验功力的，不是跑出一个漂亮的 TPS 数字，而是确认每一毫秒都花在它该在的地方。字符串拼接本身极快，但反复编译模板、重复解析 JSON、意外触发垃圾回收——这些才是并发场景下悄然吞噬性能的黑洞。