问题的本质与两类典型错误有关：控制流错误导致“二次响应”，以及异步错误未进入 Express 的错误处理链导致“未捕获的 Promise rejection”。

一、为什么会出现 Cannot set headers after they are sent

• 原因：在中间件中已调用 res.status(...).json(...) 结束响应，但仍调用 next() 把控制权交给后续路由处理器。下游再次 res.send，从而触发“响应头已发送后再次设置”的错误。
• 背后机制：Express 4 中，next() 的意义是“继续执行下一个中间件/路由”。如果你已经响应了，就不应该再 next()；否则后续逻辑可能再次尝试写入响应。
• 常见触发方式：
  • 分支里调用了 res.json 但忘了 return（或者没有任何控制流阻断），导致继续执行到 next()。
  • finally 或统一的“收尾”代码里无条件 next()。
  • 多处代码路径都可能调用 res.* 或 next()，没有保证“只调用一次”。

二、为什么会有未捕获的 Promise rejection（Node 18 下可能导致进程退出）

• 原因：使用 async 函数做中间件/路由时，内部的 await 如果抛错（或返回的 Promise reject），Express 4 并不会自动捕获并转交给错误处理中间件。最终变成未处理的 Promise rejection。
• 背后机制：Express 4 并不内建对 async/await 的错误捕获，必须手动 try/catch 并 next(err)，或者用包装器（如 asyncHandler）或第三方库（express-async-errors）。
• Node 行为：Node 15+ 默认对未处理的 Promise rejection采取“抛出并终止进程”的策略（除非你监听 process.on('unhandledRejection')）。因此在生产中会偶发进程退出。

三、诊断与思路

• 观察日志：在中间件已输出 400 响应后仍打印到路由处理器的日志，是二次响应的直接证据。
• 检查 res.headersSent：错误出现时通常为 true，再次写入会报错。
• 全局检索 res.send/res.json/res.end 调用后是否总是 return 或明确阻断；检索 next() 是否可能在已经响应后仍被调用。
• 对所有 async 中间件/路由：确认是否有 try/catch 并 next(err)，或使用统一的 async 包装器。
• 如果有并发/定时器/callback 混用：确认是否存在“多次调用 next 或 res”的竞态（例如同时在 then 与 catch 中都 next，或在计时器回调里又 next）。

四、修复建议（两种主流模式）

模式 A：就地终止响应，不再 next

• 适用场景：验证失败时直接返回错误响应，不走后续路由。

• 示例： const express = require('express'); const app = express(); app.use(express.json());

  async function validate(req, res, next) { try { const ok = await fakeCheck(req.body); if (!ok) { // 关键点：return，阻断向下传递 return res.status(400).json({ error: 'invalid' }); } return next(); } catch (err) { // 异常进入错误处理中间件 return next(err); } }

  async function fakeCheck(body) { // 实际场景里可能抛错，这里也要被 try/catch 捕获 return false; }

  app.post('/signup', validate, async (req, res, next) => { try { res.send('created'); } catch (err) { next(err); } });

  app.use((err, req, res, next) => { if (res.headersSent) return next(err); res.status(err.status || 500).json({ error: err.message || 'server error' }); });

模式 B：统一走错误管道（推荐于大项目）

• 适用场景：希望所有失败统一由错误处理中间件格式化。

• 示例： const createError = require('http-errors');

  async function validate(req, res, next) { try { const ok = await fakeCheck(req.body); if (!ok) { // 不直接响应，交给错误处理中间件 return next(createError(400, 'invalid')); } return next(); } catch (err) { return next(err); } }

  // 错误处理中间件 app.use((err, req, res, next) => { if (res.headersSent) return next(err); res.status(err.status || 500).json({ error: err.message || 'server error' }); });

五、提升健壮性的通用做法

• 使用 async 包装器，确保所有 async 路由/中间件的错误都进入 next： const asyncHandler = (fn) => (req, res, next) => { Promise.resolve(fn(req, res, next)).catch(next); };

  app.post('/signup', asyncHandler(async (req, res) => { res.send('created'); }));

• 对所有分支“只响应或只 next 一次”，并用 return 明确阻断。

• 在错误处理中间件里检查 res.headersSent，避免二次响应。

• 可临时加上 process.on('unhandledRejection', ...) 记录日志，避免无声崩溃（但根本解决还是把错误带入 Express 错误管道）。

总结

• 不能在已发送响应后再调用 next()；失败分支必须 return 或改为 next(err)。
• Express 4 不会自动捕获 async/await 的异常；需要 try/catch + next(err) 或统一包装。
• 这些是在 Node 18、Express 4 下最常见的“双响应”和“未捕获异步异常”来源。按照上述修复模式即可稳定解决。

问题现象与根因总结：

• 现象：每次请求 /poll 都会启动一个匿名 goroutine 和一个 time.Tick 驱动的轮询。请求结束后 goroutine 未退出、Ticker 未停止；并发压测会持续叠加这些后台 goroutine，runtime.NumGoroutine 不回落，CPU/内存慢慢上升，典型资源泄漏。
• 根因：
  1. 未监听 r.Context().Done。HTTP 请求的上下文会在请求完成或客户端断开时取消，未在 goroutine 中接入该信号，导致循环永不退出。
  2. 使用 time.Tick。Tick 只是 NewTicker 的包装，返回的是一个只读 channel，没有 Stop 方法。官方文档明确说明：如果不消费或无法停止，它会泄漏底层 Ticker。即便你的 goroutine在读 channel，它也会一直运行；一旦你停止读取，Ticker 的内部发送方会阻塞并常驻。
  3. 生命周期错配：将“后台轮询任务”绑定在“请求处理函数”里启动，但又不让它随请求结束而退出；在高并发下每个请求都叠加一个独立的循环与计时器，数目线性增长。
  4. 没有并发上限与清理：不限制每请求启动的后台 goroutine 数，也没有统一的回收机制或工作池。

为什么会造成 CPU/内存上升：

• 每个请求都保留至少两个 goroutine：你的匿名轮询 goroutine和底层 Ticker 的内部计时/发送 goroutine。
• Ticker 会一直调度定时事件；你的轮询 goroutine也在不断唤醒（即使只是 sleep），叠加后 CPU 的调度压力增加。
• Ticker 的 channel（容量为1）在无人读取时，发送方会阻塞并占用 goroutine 与计时器资源；大量这类阻塞 goroutine 也会被 runtime 维护，造成内存/调度开销。
• 这些资源不会在请求结束后自动释放，NumGoroutine 不回落就是直接信号。

此类场景的常见错误模式：

• 在 HTTP handler 中“顺手”开 goroutine 做后台工作，但不与请求上下文或服务生命周期绑定，导致生命周期失控。
• 忽视 context 取消：未在循环中 select ctx.Done、未给耗时操作（I/O、sleep、外部调用）传入 ctx。
• 使用 time.Tick 而非 time.NewTicker，无法 Stop，形成经典泄漏。
• 在并发入口处按请求创建定时器/轮询器，未复用/未限流，导致数量与 QPS 近似线性增长。
• 误认为“写完 w.Write 就结束了”，但忘了 handler 内部还启动了额外的永续工作。

推荐的修复与设计建议：

1. 使用 context + 可停止的 Ticker：

• 永远使用 time.NewTicker 而不是 time.Tick。

• 循环用 select 同时监听 ticker.C 和 ctx.Done。

• 退出时调用 ticker.Stop；注意 Stop 不会关闭 channel，因此必须通过 ctx.Done 驱动退出。 示例（请求作用域，随请求结束主动退出）： func pollHandler(w http.ResponseWriter, r *http.Request) { ctx := r.Context() ticker := time.NewTicker(100 * time.Millisecond) defer ticker.Stop()

  go func() { defer ticker.Stop() // 双保险：goroutine退出时停止 for { select { case <-ctx.Done(): return case <-ticker.C: // 模拟工作，最好也支持 ctx select { case <-ctx.Done(): return default: time.Sleep(10 * time.Millisecond) } } } }()

  w.Write([]byte("ok")) }

2. 更稳妥的做法：避免“每请求一个后台轮询”

• 如果轮询任务与“请求响应”无关，改为独立的后台 worker（进程级），与服务生命周期绑定；请求仅提交工作到队列或更改状态。

• 使用有界的工作池或限流机制，避免 goroutine 数量随请求无界增长。

• 若确实需要“请求期间轮询”，可以在 handler 内同步执行循环并依赖 ctx.Done 退出，而不是另启 goroutine。这样不会留后台残留： func pollHandler(w http.ResponseWriter, r *http.Request) { ctx := r.Context() ticker := time.NewTicker(100 * time.Millisecond) defer ticker.Stop()

  for { select { case <-ctx.Done(): return case <-ticker.C: // do work } } }

3. 对耗时/阻塞操作引入超时

• 给请求或任务设置 context.WithTimeout，确保最坏情况下也能退出，防止长尾导致 goroutine滞留。

4. 验证与排查手段

• 引入 net/http/pprof，在压测后查看 goroutine profile，通常能看到大量堆栈停在 “select { case <-ticker.C ... }” 或 “time.(*Ticker).loop”。
• 使用 go tool pprof + goroutine/profile、mem/profile 分析热点与数量。
• 测试阶段用 go.uber.org/goleak 侦测 goroutine 泄漏。

5. 代码约束与团队约定

• 禁止在 handler 中使用 time.Tick。
• 在任何长期循环中强制 select <-ctx.Done。
• 后台任务必须明确生命周期：请求作用域、服务作用域、或外部任务系统；并为每类作用域定义退出策略。
• 对每请求启动 goroutine 建立并发上限（信号量/池），监控并报警 goroutine 数超限。

核心思路的记忆点：

• Tick 会泄漏；Ticker要Stop；循环要听Done。
• 请求上下文就是你的退出信号；所有与请求相关的后台工作都应绑定它。
• 不要让工作模型随着请求无界扩张；将轮询/定时器设计为进程级单例或池化。