服务器实测状态
| 指标值 | |
| CPU | 8核，当前负载 0.00（几乎空闲） |
| 内存 | 16GB，已用 1.6GB，可用 13GB |
| 磁盘 | 40GB SSD，已用 10GB |
| 带宽 | 10Mbps（≈1.19 MB/s 实际吞吐） |
| Nginx | 1.28.3，8 worker，51200 连接/worker |
| Node.js | v24.15.0，PM2 fork 单进程（97MB 内存） |
| MySQL | 5.7.44，最大连接 500，缓冲池 1GB |
| HTTP/2 | 已开启 |
| Gzip | 已开启（level 5） |
| 静态资源缓存 | 30天 immutable |
瓶颈分析
带宽是首要瓶颈（10Mbps = 1.19 MB/s）：
对于文章/图片场景，一次页面加载均重约 30-50KB（HTML+API 数据 ~5KB，首屏图片 ~30KB）。JS/CSS 有 30 天强缓存，回访用户几乎不产生这部分流量。
| 访问类型单次流量10Mbps 下每秒可承载 | ||
| 纯文字页面（已缓存资源） | ~3-5 KB | ~250-400 次/秒 |
| 图文页面（1-2张图） | ~30-50 KB | ~25-40 次/秒 |
| 首访（无缓存 JS/CSS） | ~400-500 KB | ~2-3 次/秒 |
后端是次要瓶颈：
- 当前 Node.js 单进程（fork 模式），通常可处理 200-500 req/s 简单查询
- MySQL 实际最大连接数历史峰值仅 12，远未触及 500 上限
Nginx 不是瓶颈： 8 × 51200 = 40 万理论并发连接，somaxconn 4096，远超带宽能支撑的量。
容量评估
同时在线人数
按用户阅读一篇文章 30-60 秒、期间产生 2-3 个 API 请求计算：
| 场景估算并发 | |
| 日常舒适（图文混合，70% 回访） | 500-800 人 |
| 峰值可承受 | 1,500-2,000 人 |
| 带宽打满极限 | ~3,000 人 |
日访问量（PV）
按每天 12 小时活跃时段（大学生作息）、平均负载率 50%：
| 指标估算值 | |
| 日 PV（日常） | 20-30 万 |
| 日 PV（峰值） | 50-80 万 |
| 日 UV（人均 5 页） | 4-6 万（日常）/ 10-15 万（峰值） |
理论极限
10Mbps × 86400s ÷ 8 ÷ 30KB(均页重) ≈ 170 万 PV/天
但受峰值/低谷分布制约，实际不可能跑满。合理日 PV 上限约 80-100 万。
改进建议
当前单进程 Node.js 只用了 1/8 的 CPU，按目前流量完全够用。如果日后用户增长到预估峰值，有两个低成本升级点：
- PM2 开启 cluster 模式（多进程利用多核）：改
fork为cluster，实例数设为 2-4，后端吞吐可翻倍 - 带宽升级：10Mbps 是最终瓶颈，升级到 20-30Mbps 成本很低但效果立竿见影
当前服务器配置对于大学城区域用户（23 所院校、18 万师生），完全足以支撑日常运行。