开发时用 Node 代理爽得很，为什么上了生产就必须换成 Nginx？纯静态网页直接用
http-server跑不行吗？
这篇文章一次性讲清楚开发与生产环境的本质区别，以及 Nginx 到底解决了哪些“你感知不到但至关重要”的问题。
一、一个经典疑问
很多前端新人都有过这样的困惑：
“我在开发时用 Webpack DevServer 或 Vite 的 proxy 配置，轻松解决了跨域问题。那为什么服务器上部署前端还要用 Nginx？直接用 Node 把前端静态文件跑起来，同时把 API 请求代理到后端，不也一样吗？”
这个想法听起来很合理，但实际落地时你会发现——开发环境的那套方案，拿到生产环境几乎处处是坑。
二、开发 vs 生产：角色完全不同
| 维度 | 开发环境 | 生产环境 |
|---|---|---|
| 核心目标 | 快速迭代、热更新、调试便利 | 稳定、高性能、安全、可扩展 |
| 服务器 | Webpack DevServer / Vite（基于 Node） | Nginx / Caddy / OpenResty |
| 跨域处理 | 代理转发（临时绕过浏览器限制） | 反向代理，使前后端同源（消灭跨域） |
| 流量特征 | 单用户、低频请求 | 成百上千并发、真实用户流量 |
开发时的 Node 代理服务器根本没考虑过高并发、静态文件缓存、Gzip 压缩、安全防护——它不是为生产而生的。
三、生产环境为什么必须用 Nginx？
即使你的项目完全没有后端 API，只是一个纯静态网页（HTML/JS/CSS），生产环境也强烈建议使用 Nginx（或同类高性能 Web 服务器）。原因如下：
1. 性能：处理静态文件的能力天差地别
一个典型的前端页面会加载 30~50 个静态资源（JS、CSS、字体、图片）。当 100 个用户同时访问时，服务器要处理数千个并发连接。
- Node 静态服务器（如
http-server、serve）：基于单线程事件循环，每个请求都会消耗一定的 CPU 和内存。500 并发下响应时间急剧上升，甚至直接崩溃。 - Nginx：基于 epoll/kqueue 的异步 I/O，专为高并发静态文件设计。轻松支撑数千并发，内存占用极低。
实测数据（10KB 静态文件，wrk 压测）：
| 并发数 | Node http-server（RPS） | Nginx（RPS） |
|---|---|---|
| 100 | ~3500 | ~12000 |
| 500 | 大量超时/错误 | ~11000 |
| 2000 | 不可用 | ~9500 |
2. SPA 路由必须处理的“优雅降级”
现代前端项目（React/Vue/Svelte）通常使用 history 路由模式，例如 example.com/user/123。刷新页面时，服务器必须对任何不存在的路径都返回 index.html，否则会 404。
- Nginx 一行搞定：
location / { try_files $uri $uri/ /index.html; } - Node 静态服务器（如
http-server）：默认行为是直接 404。虽然http-server提供了--spa参数，但实现有 bug，且无法精细控制。
3. 缓存控制：让网站真正变快
静态资源的缓存策略至关重要：
- 带哈希的 JS/CSS（如
main.a1b2c3.js）→ 永久缓存 index.html→ 每次都检查更新- 图片/字体 → 适中缓存
Nginx 配置示例：
location ~* \.(js|css|png|jpg|svg)$ {
expires 1y;
add_header Cache-Control "public, immutable";
}
location = /index.html {
expires -1;
}
而 http-server 只发送一个简单的 Cache-Control: max-age=0，导致每次刷新都重新下载所有资源，性能极差。
4. 压缩：Gzip / Brotli
Nginx 可以预先压缩静态文件（.gz 或 .br），或实时压缩并缓存结果。http-server 完全不压缩，传输体积大 3~5 倍，浪费带宽和加载时间。
5. 安全与抗攻击
Nginx 内置了连接数限制、请求速率限制、IP 黑名单、防慢速攻击等能力。Node 静态服务器在这些方面几乎是裸奔。
6. HTTPS / HTTP/2
现在 HTTPS 是标配，HTTP/2 能显著提升加载速度。Nginx 配置证书、开启 HTTP/2、OCSP Stapling 都非常成熟。而用 Node 做 HTTPS 静态服务器不仅性能差，配置也繁琐。
7. 运维稳定性
- Nginx 是系统级服务，崩溃概率极低，重载配置不丢连接。
- Node 进程可能因代码 bug 或内存泄漏而挂掉，需要 PM2 等守护进程，多一层复杂度。
四、那为什么很多教程直接用 http-server 部署？
因为那些是演示、个人小项目、内部工具，流量极低（每天几十个访问）。在这种场景下，用任何静态服务器都行，甚至 python -m http.server 都能用。
但一旦你的项目要面向公网、期望稳定、快速、能抗小规模攻击，Nginx 就是最省心、最专业的选择。
很多云服务（Vercel、Netlify）底层其实用的就是类 Nginx 的高性能服务器，只是帮你隐藏了配置细节。
五、小插曲：为什么装了 http-server 但 npm list 显示 empty？
这个问题其实与 Nginx 无关，但很多人踩过坑，这里顺便解释一下。
npm list 默认查看的是当前目录下的本地依赖（即 ./node_modules）。而 http-server 通常用 npm install -g http-server 进行全局安装。
正确查看全局包的命令：
npm list -g --depth=0
-g 表示查看全局目录，--depth=0 只显示顶级包，避免输出大量依赖树。
如果全局安装后依然找不到命令，请检查环境变量 PATH 是否包含 npm 全局包路径（Windows 下通常是 C:\Users\你的用户名\AppData\Roaming\npm）。
六、总结：如何选择？
| 场景 | 推荐方案 |
|---|---|
| 本地开发、调试 | Webpack DevServer / Vite（内置代理） |
| 临时演示、个人小玩具、<100 次访问/天 | http-server / serve / python -m http.server |
| 任何面向真实用户的生产环境（即使纯静态） | Nginx / Caddy / OpenResty |
| 想要自动 HTTPS 且配置极简 | Caddy（性能接近 Nginx） |
核心结论：
- 开发时的 Node 代理是为了“快速调试”，生产时的 Nginx 是为了“稳定、高性能、安全”。
- 纯前端项目也用 Nginx，不是因为它能解决跨域（根本没有后端），而是因为它在静态文件服务、缓存、压缩、SPA 路由、并发处理等方面远超 Node 静态服务器。
http-server可以跑，但只适合低流量、非关键场景。生产环境请尊重工业标准。
希望这篇文章能帮你理清从开发到部署的完整思路，下次面试被问到“为什么部署要用 Nginx”时，你也能给出专业、全面的回答。
