🚀 Next.js API 压力测试：一场前端与后端的“极限拉扯”

🍳 引子：当服务端开始"喘气"

有一天，你部署好的 Next.js API 源源不断地收到请求。

日志在狂刷，服务器开始发热，风扇叫得像火箭要起飞。

于是你思考：

"我到底能抗住多少请求？

是轻风拂面，还是台风压顶？"

答案只有一个办法能知道 ------ 压力测试（Load Testing） 。

🧩 一点点底层原理铺垫

在 Next.js 中，API Routes 本质上就是一个 Node.js HTTP handler 。

每个请求，Next.js 都会封装为一个 IncomingMessage 加上 ServerResponse，

并交给对应的函数处理。

简单点说，压上来的请求就像一群人往你的店门冲：

Node.js 的事件循环（Event Loop） 像店长，一个人跑前跑后。
Libuv 的线程池 是后厨做咖啡、切面包的地方。
V8 引擎 则负责计算账单，判断哪位顾客先来后到。

因此，Next.js API 的抗压能力，往往取决于这三者之间的协调速度。

🛠️ 准备一条"待拷问"的 API

创建一个最简单的 API 路由，模拟服务端业务处理：

javascript 复制代码

// pages/api/hello.js
export default async function handler(req, res) {
  // 模拟一个"CPU 小任务"
  const work = Array(10000)
    .fill(0)
    .reduce((a, b) => a + b, 0);

  // 模拟异步 I/O 消耗
  await new Promise((resolve) => setTimeout(resolve, 50));

  res.status(200).json({ message: "你好，世界！", sum: work });
}

这里我们让请求稍微"忙"一点：

既动了 CPU，又歇了 I/O，是经典的"工作加摸鱼"的混合型选手。

⚙️ 构建一个简易压测脚本

接下来，用 Node.js 原生能力（或者你钟爱的 axios）来模拟一波请求轰炸。

javascript 复制代码

// loadtest.js
import http from "http";

const CONCURRENCY = 100; // 同时并发数
const REPEAT = 10; // 每个客户端发多少次请求
const TARGET = "http://localhost:3000/api/hello";

async function shoot() {
  return new Promise((resolve) => {
    const start = Date.now();

    http.get(TARGET, (res) => {
      res.on("data", () => {});
      res.on("end", () => {
        const duration = Date.now() - start;
        resolve(duration);
      });
    });
  });
}

async function main() {
  const promises = [];
  for (let i = 0; i < CONCURRENCY * REPEAT; i++) {
    promises.push(shoot());
  }

  const results = await Promise.all(promises);
  const total = results.reduce((a, b) => a + b, 0);
  const avg = (total / results.length).toFixed(2);

  console.log(`🔥 请求总数：${results.length}`);
  console.log(`🧭 平均响应时间：${avg} ms`);
}

main();

在运行时，务必小心：

别在生产环境里执行，否则你会和自己展开一场"内乱"。

🧮 小小性能分析（不用公式也能算）

假设你跑出来的数据是这样的：

测试条件	每秒处理请求数	平均响应时间
并发 10	约 200 req/s	50 ms
并发 100	约 80 req/s	300 ms
并发 500	约 20 req/s	1200 ms

你会发现：

请求量一多，就像地铁高峰期 ------ 每个人都要排队，

Node.js 虽然是异步的，但操作系统调度 CPU 还是有限的。

🚶‍♂️ 越多的并发，不代表越快，

它更像是一锅水，越烧越沸腾，

最后会溢出来。

🧠 探究：为什么慢？

压力测试慢的原因常见有：

事件循环积压 ------ 太多 await 或者同步运算。
I/O 堵车 ------ 请求数据库、访问外部服务耗时。
GC（垃圾回收）频繁 ------ 对象分配太多，V8 疲惫不堪。
冷启动惩罚 ------ 函数初次执行时加载模块消耗时间。

可以用 autocannon, wrk 或者 Artillery 来更真实地测，但核心原理都一样：

"你的 Node.js 服务，就像一条高速路，

每一次 await，都是一个收费站。"

🧰 优化建议（不整花活，整硬核）

合理分配异步任务：避免 CPU 密集运算直接在主线程跑。
缓存！缓存！缓存！ ：例如 Redis 或内存缓存。
负载均衡：多实例部署，用 Nginx 或 Load Balancer 扛住并发。
Profiling 工具上阵 ：clinic.js、node --inspect、0x 都是好帮手。

📜 尾声：让服务器优雅地跳探戈

记住，压力测试不是用来把服务器干趴的 ，

而是用来了解它的"呼吸节奏"。

我们要知道，在它还健康愉快地处理请求之前，

哪里可以优化，哪里可能猝不及防地爆掉。

当你能从每一组测试结果里读出系统的生命律动，

那你就不只是个程序员了，而是一名"数字聆听者"。