1. 为什么突然想搞一次 Django 部署性能调研先说个大实话Django 项目本地跑得飞起一上服务器就卡成 PPT这种事儿我见过太多次了。而且更诡异的是同样的代码有的人用 Nginx Gunicorn 部署有的人用 Uvicorn 跑 ASGI还有的人干脆 Docker 一把梭最后测出来的并发表现能差好几倍。我这次做不同Django服务器和部署方式的性能调研起因其实很现实——手头有个模拟项目X要上线预估峰值并发三百左右不算高但也不能随便拍脑袋选方案。网上的文章大多是单点对比什么Gunicorn比Uvicorn快、Docker比裸机慢这类结论看得我头大因为脱离场景谈性能都是耍流氓。所以我干脆自己搭了一套环境把主流方案拉出来在可控条件下逐个测了一遍。这篇文章就是这次调研的完整记录包括测试方法、实测数据、参数调优思路还有我踩过的坑。如果你也在纠结我的 Django 项目到底该怎么部署这篇文章应该能帮你省下不少试错时间。先说清楚本文所有测试数据均来自我自己的测试环境机器配置、并发模型、压测工具参数我都会写明白。你复现的时候数据可能不一样但结论趋势和排查思路是通用的。2. Django 部署方式全景梳理各方案的真实定位2.1 部署一个 Django 项目到底需要几层东西很多人第一次部署 Django 时会懵是因为搞不清服务器这个词到底指哪一层。实际上一个完整的 Django 生产环境至少包含三层第一层是 Web 服务器比如 Nginx 或 Caddy负责接收 HTTP 请求、处理静态文件、做反向代理。这一层不跑 Django 业务代码但它决定了请求能不能高效地到达后端。第二层是应用服务器这才是真正跑 Django 代码的地方。Gunicorn、Uvicorn、 Daphne 都属于这一层。它们把 Python 代码跑起来处理业务逻辑、访问数据库、返回响应。第三层是 ASGI/WSGI 协议本身。Django 3.0 之后官方开始支持 ASGI但很多老项目还在用 WSGI 模式跑。这两者的区别直接决定了你选 Gunicorn 还是 Uvicorn。我见过有人在裸的 runserver 上直接上线结果一有并发就报错——runserver 是开发服务器根本不是干这个用的。生产环境至少得是 Nginx 应用服务器 Django 的经典组合。2.2 主流方案分类与核心选型逻辑这次调研我选了五个方案基本覆盖了目前最常见的部署组合第一个是 Gunicorn 同步 Worker最经典的 WSGI 部署方式配 Nginx 使用。适合绝大多数传统 Django 项目尤其是以同步视图为主的业务系统。第二个是 Gunicorn gevent Worker通过协程来提升并发能力适合 IO 密集型的场景比如大量数据库查询或外部 API 调用。第三个是 Uvicorn纯 ASGI 服务器适合 Django Channels 或异步视图。如果你用 DRF 写异步接口这个方案是自然选择。第四个是 Uvicorn Gunicorn 组合用 Gunicorn 管进程Uvicorn 跑 Worker兼顾进程管理和异步能力。第五个是 Docker 容器化部署里面跑 Gunicorn 或 Uvicorn前面配 Nginx 或 Traefik。适合需要快速扩缩容、环境一致的团队。选型的核心逻辑其实就一句话先看你项目的 Django 版本和视图写法再决定走 WSGI 还是 ASGI 路线。纯同步项目硬上 Uvicorn 不会变快异步项目用 Gunicorn 同步 Worker 反而会浪费性能。2.3 性能瓶颈通常不在Django 本身调研前我先把性能瓶颈这件事想清楚了。Django 框架本身的渲染和请求处理其实不是最大开销真正吃性能的是数据库查询、模板渲染、Session 管理、中间件处理这些环节。举个例子一个视图函数里如果做了三次数据库查询每次 50ms那这个接口光是查库就花了 150ms。这种情况下你换什么服务器都救不回来。所以部署方式的性能调研必须加上业务代码固定不变这个前提否则测出来的数据根本没意义。我在设计测试方案时特意把业务逻辑控制在最简避免数据库成为瓶颈这样才能真正对比出不同部署方式的差异。后面你看到的数据反映的是部署层本身的性能差距不是业务代码的好坏。3. 测试环境设计与压测方法控制变量的关键3.1 硬件环境与软件版本清单这次测试我用了两台同一配置的云主机一台跑 Django 应用一台跑压测工具避免压测工具本身抢占应用资源导致数据失真。应用服务器的配置是四核 CPU、8GB 内存、SSD 系统盘操作系统是 Ubuntu Server LTS 版本。Python 版本 3.10Django 版本 4.2 LTS数据库用的 PostgreSQL 14。压测机配置与应用服务器完全一致用的压测工具是 wrk 和 ApacheBench 双验证。wrk 适合测高并发下的吞吐量ApacheBench 适合测固定并发下的响应时间两者结合起来数据更有说服力。这里有个容易忽略的点wrk 本身跑在单线程上如果你要压很高并发得用 wrk2 或者多开几个 wrk 进程。我这次压测峰值并发 500单 wrk 进程勉强够用但超过 800 就建议用分布式压测了。3.2 测试接口设计避免业务逻辑干扰为了对比部署层性能我设计了三个测试接口第一个是纯 JSON 返回接口不查数据库不渲染模板模拟最简单的 API 请求。这个接口测的是 Web 服务器和应用服务器本身的极限能力。第二个是带模板渲染的页面接口用 Django 模板引擎渲染一个包含列表数据的页面。这个接口测的是模板渲染对性能的影响。第三个是带数据库查询的接口从 PostgreSQL 里查询一百条数据再返回 JSON。这个接口最接近真实业务但同时引入了数据库变量所以我在对比部署方式时主要看前两个接口的数据。测试过程中我反复确认了一个细节——所有接口的代码完全一致只改部署配置不改业务代码。这是控制变量的铁律后面测出来的数据差异才能归因于部署方式本身。3.3 压测参数与执行策略压测参数我分了三个档位并发 50、并发 200、并发 500。每个档位持续压测 60 秒取稳定后的数据。为什么选这三个档位并发 50 代表中小型项目的日常流量并发 200 代表促销或活动场景并发 500 基本就是服务器能力的上限测试了。再往上压其实意义不大因为真实业务场景里单机扛 500 并发已经足够大多数项目使用。每次压测前我都会重启应用服务器确保没有残留连接影响结果。压测过程中监控 CPU、内存、文件描述符三个指标因为有时候吞吐量没降但响应时间涨了说明系统已经在排队了。我用 wrk 的脚本输出每秒请求数和延迟分布再用 Python 脚本解析结果生成报告。重复测三轮取中位数避免偶发波动干扰结论。4. Gunicorn 同步 Worker 实测最稳但不一定最快4.1 基础配置与启动参数Gunicorn 同步 Worker 是 Django 部署最经典的方案配 Nginx 用了快十年了吧。它的工作原理很简单每个 Worker 进程一次只能处理一个请求请求处理完才能接下一个。我用的启动命令是gunicorn myproject.wsgi:application \ --bind 0.0.0.0:8000 \ --workers 4 \ --worker-class sync \ --timeout 30 \ --keep-alive 5 \ --max-requests 1000 \ --max-requests-jitter 100Worker 数量这块官方推荐是 CPU 核数乘以 2 再加 1也就是2 * CPU 1。我四核机器按这个公式该配 9 个 Worker但我实际测过纯 CPU 密集场景下 4 个 Worker 反而更好因为多出来的 Worker 会抢 CPU 时间片。这个公式适用于大多数 IO 密集业务但如果你接口里有大量 CPU 计算就适当减少 Worker 数量。我最终配了 4 个 Worker因为测试接口不涉及密集计算4 个刚好够用。4.2 实测数据并发 50 到 500 的表现同步 Worker 在并发 50 时的表现相当稳每秒请求数约 1800P99 延迟在 45ms 左右。这个数据对于大多数中小项目来说已经完全可以接受。并发提到 200 时同步 Worker 开始出现性能拐点每秒请求数降到 1500 左右P99 延迟涨到 120ms。虽然吞吐量没有崩但延迟增长明显说明 Worker 开始排队了。并发 500 时同步 Worker 的表现就不太行了每秒请求数掉到 900P99 延迟飙到 380ms。原因很好理解——只有 4 个 Worker每个 Worker 同一时间只能处理一个请求剩余 496 个请求全部在排队等待。这个数据告诉我们一个道理同步 Worker 的并发能力受 Worker 数量硬限制适合业务逻辑简单、单请求处理时间短的场景。如果你的接口动辄几百毫秒的数据库查询同步 Worker 根本扛不住并发。4.3 同步模式的适用场景与优化空间同步 Worker 最大的优势是稳定、可预测、排错简单。每个请求一个进程不会有协程切换的心智负担出问题直接用 py-spy dump 进程栈就能定位。优化空间方面我觉得有两点值得做。第一是调大keep-alive参数让客户端复用连接减少握手开销。第二是配合max-requests定期重启 Worker防止内存泄漏累积。但说实话如果你的项目并发要求真的超过 300我不推荐纠结同步 Worker 的优化而是应该换方案。同步 Worker 的性能天花板就在那里再怎么调也突破不了一进程一请求的模型限制。5. Gunicorn gevent WorkerIO 密集型场景的加速器5.1 协程如何突破进程数限制gevent Worker 是 Gunicorn 的协程模式核心思路是在一个进程内用 greenlet 协程处理多个请求。协程切换的开销远小于进程切换所以同样的 Worker 数量下gevent 能承载的并发数要高出很多。我之前做过一个比喻同步 Worker 就像银行柜台每个柜台一次只能服务一个人人多就得排队gevent Worker 就像柜台里多了好几个流动服务员虽然柜台数量没变但能同时接待的人变多了。启动命令和同步模式差别不大gunicorn myproject.wsgi:application \ --bind 0.0.0.0:8000 \ --workers 4 \ --worker-class gevent \ --worker-connections 1000 \ --timeout 30关键参数是worker-connections它控制每个 Worker 能同时处理的连接数。我设的 1000意味着 4 个 Worker 理论上能同时处理 4000 个连接。当然这只是理论值实际受 CPU 和内存限制。5.2 纯 IO 场景实测吞吐量翻倍的真实数据gevent 模式在纯 JSON 接口上的表现让我有点意外。并发 50 时每秒请求数约 2300比同步 Worker 提升了约 28%P99 延迟在 38ms 左右。并发 200 时的差距拉开了每秒请求数 2100P99 延迟 85ms。虽然吞吐量只比同步模式高 40%但延迟增长曲线平滑得多说明协程在处理并发时更从容。并发 500 时才开始出现明显瓶颈每秒请求数掉到 1400P99 延迟 210ms。这个表现比同步 Worker 的 900 请求/秒和 380ms 延迟强了不少差距接近一倍。但我得提醒一句gevent 的快是建立在 IO 密集型场景上的。如果你的业务代码里有大量 CPU 计算gevent 的协程切换反而会引入额外开销性能甚至不如同步 Worker。5.3 gevent 的隐形坑代码兼容性gevent 最大的坑不在于性能而在于代码兼容性。它通过 monkey-patch 把标准库里的 socket、select 等阻塞调用改成协程调度但如果你的项目用了某些不兼容的 C 扩展库就会出现诡异的问题。比如我这次测试用的 PostgreSQL 驱动如果用了 psycopg2 而不是 psycopg2 的 gevent 兼容版本在协程模式下会出现连接池报错。换成 psycopg2-binary 配合 gevent 的 socket 补丁后问题才解决。另外如果你的 Django 项目用到 Celery 或某些后台任务框架gevent 模式下要注意它们的事件循环是否兼容。我建议在切换 gevent 前先跑一遍完整的集成测试别只看压测数据好看就上线。6. Uvicorn 纯 ASGI 模式实测异步的正确打开方式6.1 ASGI 与 WSGI 的本质区别Uvicorn 是纯 ASGI 服务器它和 WSGI 最大的区别在于支持异步视图和 WebSocket 长连接。Django 3.0 后引入 ASGI 支持但很多项目至今还在用 WSGI 模式根本原因是异步改造的成本高、收益不直观。我用一个简单的比喻来解释WSGI 是打电话一次只能聊一件事聊完挂断ASGI 是微信聊天可以同时开多个窗口消息可以异步收发。实际测试中我用 Django 的异步视图写了一个模拟接口用 async def 定义内部用 asyncio.sleep 模拟 IO 等待。这个接口在 Uvicorn 下并发 500 的表现就很能说明问题——每秒请求数 1700P99 延迟 160ms。6.2 Uvicorn 与 Database 访问的适配问题这里要特别提醒一点Uvicorn 跑异步视图时如果数据库操作还是同步的性能反而会下降。因为同步的数据库调用会阻塞事件循环导致后续请求全部排队。我在测试里专门对比了两种情况异步视图 同步数据库查询以及异步视图 异步数据库查询。前者在并发 200 时延迟就飙到 300ms 以上后者则在同样并发下保持 80ms 左右。如果你的 Django 项目目前是纯同步视图我建议不要因为Uvicorn 听起来更高级就换过去。同步代码跑在 Uvicorn 上跟跑在 Gunicorn 上没本质区别反而可能因为 Uvicorn 的进程管理不如 Gunicorn 完善而增加运维成本。6.3 Uvicorn 单独用还是配合 Gunicorn 用这是一个不少人在纠结的问题Uvicorn 到底单独跑还是配合 Gunicorn 跑单独跑 Uvicorn 的命令很简单uvicorn myproject.asgi:application \ --host 0.0.0.0 \ --port 8000 \ --workers 4 \ --loop asyncio \ --http h11但 Uvicorn 自带的 Worker 管理比较简陋不像 Gunicorn 有成熟的信号处理、优雅重启、超时管理。所以我更推荐用 Gunicorn 作为进程管理器Uvicorn 作为 Workergunicorn myproject.asgi:application \ --bind 0.0.0.0:8000 \ --workers 4 \ --worker-class uvicorn.workers.UvicornWorker \ --timeout 30这种方式既保留了 Gunicorn 的运维能力又获得了 Uvicorn 的异步处理能力是我个人比较推荐的生产方案。7. Nginx 反代层的作用别让性能损耗在入口7.1 Nginx 配置对 Django 性能的影响很多人会忽略一个事实Nginx 作为反向代理层它的配置直接决定了 Django 应用能不能高效工作。尤其在高并发场景下Nginx 配置不当反而会成为瓶颈。我的 Nginx 配置核心部分长这样upstream django_backend { server 127.0.0.1:8000; keepalive 32; } server { listen 80; server_name example.com; client_max_body_size 20m; keepalive_timeout 5; location /static/ { alias /var/www/myproject/static/; expires 30d; access_log off; } location / { proxy_pass http://django_backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_http_version 1.1; proxy_set_header Connection ; } }关键点在于proxy_http_version 1.1和proxy_set_header Connection 。默认情况下 Nginx 向后端转发用的是 HTTP/1.0每次请求都要新建连接Django 端来不及复用连接性能损耗很明显。改成 HTTP/1.1 并清空 Connection 头之后Gunicorn 的 keep-alive 才能真正生效。7.2 静态文件处理一个被低估的性能优化点Django 处理静态文件的性能很糟糕因为它要通过 Python 代码去读文件、拼路径、设置响应头。Nginx 处理静态文件则是直接读磁盘返回性能差距在十倍以上。所以生产环境必须把静态文件交给 Nginx 处理Django 只处理动态请求。我见过不少项目把静态文件硬塞给 Django 处理结果并发一上来光是静态文件请求就把 Worker 拖垮了。在测试中做了个对比静态文件走 Django 和应用服务器每秒只能处理 800 个请求走 Nginx 后每秒能处理 8000 个以上。这个差距足以说明问题。7.3 负载均衡与多实例扩展Nginx 的另一个价值在于负载均衡。当单台 Django 应用扛不住时可以起多个实例Nginx 按轮询或 least_conn 策略分发请求。我这次测试虽然只用了一个 Django 实例但 Nginx 的 upstream 配置里预留了多台机器的扩展位。实际上生产环境里一台 Nginx 后面挂三五台 Django 应用是很常见的架构Nginx 的健康检查配合自动摘除故障节点比 DNS 轮询靠谱得多。部署调优时链路里每一层都可能成为瓶颈。Nginx 层、应用服务器层、数据库层必须逐层排查不能只盯着 Django 本身的代码。8. Docker 容器化部署性能损耗到底有多少8.1 Docker 部署的配置方案Docker 部署在现代运维中几乎是标配了好处是环境一致、快速扩缩容、CI/CD 友好。但很多人关心的是性能损耗容器化到底会让 Django 慢多少我这次的容器化方案是 Django 应用跑在 Docker 容器里Gunicorn 作为应用服务器Nginx 在宿主机上做反向代理。这种方式比全部容器化少了一层网络开销性能损耗更小。Dockerfile 的核心内容FROM python:3.10-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . EXPOSE 8000 CMD [gunicorn, myproject.wsgi:application, --bind, 0.0.0.0:8000, --workers, 4]需要注意几点基础镜像尽量用 slim 版本减小体积依赖安装用--no-cache-dir避免缓存文件占用空间启动命令直接写 CMD方便替换。8.2 容器化与裸机部署的实测对比容器化实测数据让我松了口气——性能损耗并没有想象中那么大。并发 50 时容器化的每秒请求数约 1700比裸机部署的 1800 低了约 5%。并发 200 时容器化约 1400裸机约 1500损耗也在 7% 以内。并发 500 时差距稍微拉大容器化每秒请求数 820裸机 900损耗约 9%。这个损耗主要来自 Docker 的网络隔离和存储驱动开销对于大多数业务场景完全可以接受。真正影响 Docker 性能的不是容器本身而是镜像里的 Python 版本和依赖库版本。如果镜像里装了一堆不需要的包内存和 CPU 开销都会增大性能自然下降。8.3 Docker 网络模式的选择Docker 的网络模式对性能影响很大尤其是高并发场景。我测试了 bridge 模式和 host 模式数据差异不小。bridge 模式下容器内的 Gunicorn 监听 8000 端口宿主机 Nginx 通过 port mapping 转发请求每次请求会多一层 NAT 转发延迟大概增加 1-2ms。host 模式下容器直接共享宿主机网络栈Gunicorn 监听宿主机的 8000 端口没有 NAT 开销性能更好。但代价是端口管理混乱多容器部署时容易端口冲突。如果追求极致性能我建议用 host 模式如果想保持容器隔离性和可管理性bridge 模式多出来的几毫秒延迟其实可以接受。9. 测试数据汇总与方案选型建议9.1 五方案性能对比总表我把五个方案在不同并发下的数据汇总成一张表方便你直接对比部署方案并发50 QPS并发50 P99(ms)并发200 QPS并发200 P99(ms)并发500 QPS并发500 P99(ms)Gunicorn 同步1800451500120900380Gunicorn gevent2300382100851400210Uvicorn 异步视图2200401900901700160Uvicorn Gunicorn2100421850881650150Docker Gunicorn1700521400130820400注意Uvicorn 的数据是在异步视图 异步数据库查询的前提下测的。如果你的项目是同步视图Uvicorn 的实际表现会接近 Gunicorn 同步模式数据要打折扣。9.2 不同业务场景下的选型建议基于这些数据我给不同场景的选型建议如下如果你的项目是传统同步 Django 项目数据库查询为主并发需求在 100 以内我建议直接选 Gunicorn 同步 Worker 配 Nginx。稳定、易排错运维成本最低没必要为了追求数据好看而引入协程或异步。如果项目 IO 密集但视图是同步的比如大量调用外部 API 或数据库查询频繁Gunicorn gevent 是首选。改造量极小只需换 Worker 类性能提升却很显著。如果项目已经用了 Django Channels 或写了大量异步视图Uvicorn 配 Gunicorn 是合理方案。建议用 Gunicorn 管理进程避免 Uvicorn 独立部署时的运维短板。如果团队有成熟的 Docker 运维体系容器化部署完全没问题性能损耗不到 10%。但要注意网络模式的选择和镜像体积控制。9.3 性能调优的优先级排序最后说一点个人经验部署方式只是性能优化的一环而且往往不是最关键的一环。我见过太多人纠结 Gunicorn 和 Uvicorn 哪个快却忽略了数据库索引缺失、N1 查询、模板重复渲染这些真正要命的问题。我建议的性能调优优先级是这样的先优化数据库加索引、减少查询次数、加缓存再优化业务代码减少循环里的 IO 操作合并多个接口最后才优化部署层调 Worker 数量、换协程模式、容器化。顺序反了的话你会发现部署层再怎么调吞吐量也很难有质的飞跃。10. 调研过程中的踩坑记录与排查方法10.1 Gunicorn 的 Timeout 导致的假低并发测试时遇到一个很奇怪的现象并发 200 时有一些请求超时返回 504但 CPU 和内存占用都不高。排查了半天发现是 Gunicorn 的默认 timeout 是 30 秒而压测时的慢请求拖垮了 Worker。关键问题在于压测工具 wrk 本身不会等响应它会持续发请求。当某个请求处理超过 30 秒时Gunicorn 会杀掉 Worker 重启这个过程中新请求全部排队表现就是吞吐量骤降。解决方法是把 timeout 调大到 60 秒同时检查业务代码里有没有长时间阻塞操作。排查后发现有一个视图函数调用了外部 API 且没有设置超时网络抖动时能卡住几分钟这才是真凶。10.2 Uvicorn 的 Worker 数误区Uvicorn 的--workers参数和 Gunicorn 的--workers逻辑不一样Uvicorn 每个 Worker 都是独立的事件循环如果配置太多反而会因为线程切换增加开销。我测试过程中把 Uvicorn Worker 从 4 加到 8结果吞吐量没升反降CPU 占用却翻了一倍。原因是每个事件循环都要维护大量的 socket 连接和定时器Worker 太多时资源消耗反而超过收益。实测下来Uvicorn 的 Worker 数量应该控制在 CPU 核数以内四核机器配 2-4 个 Worker 就够了。如果单 Worker 的异步处理能力不够说明你的代码里有同步阻塞操作加 Worker 只是治标不治本。10.3 wrk 压测本身可能成为瓶颈压测工具本身也可能是瓶颈这个坑很多人没意识到。wrk 默认使用单线程但你压到高并发时单线程的 wrk 可能自己先扛不住产生错误的压测结果。我后来用 htop 监控压测机的 CPU发现并发 500 时 wrk 进程的 CPU 已经打满了。这意味着压测结果反映的是 wrk 的能力上限而不是 Django 应用的性能上限。解决方法是多开几个 wrk 进程或者用 wrk2 精确控制请求速率。数据稳定后和单 wrk 的结果对比才能确认压测数据的有效性。11. 后续扩展从单机部署到集群架构这次的调研都建立在单机部署的维度上但真实生产环境往往不止一台机器。我最后想聊聊从单机到集群的扩展路径顺便分享一些实测经验。单机部署的扩展路径一般是这样的单台 Nginx 单台 Django 应用 单台数据库这是最基础的架构。当流量增长到单机扛不住时第一步优化通常是升级硬件配置比如加 CPU 核数、加内存而不是急着上集群。硬件升级解决不了问题时第二步是拆层部署Nginx 单独一台Django 应用单独一台或几台数据库单独一台。这样各层之间不会互相抢占资源性能瓶颈更容易定位。第三步就是上集群了多台 Django 应用实例共享一个负载均衡入口数据库做读写分离或主从复制。这时候容器化和编排工具的价值就体现出来了可以快速扩缩容。我在测试环境里模拟了一个两台 Django 应用实例 Nginx 负载均衡的架构并发 500 时总体吞吐量能达到 2600 QPS几乎翻倍。当然这需要数据库层面做好连接池管理否则应用实例翻倍带来的数据库连接数暴涨会把数据库压垮。扩展集群时数据库连接数管理是第一个要解决的问题。Django 每个应用实例都会建立数据库连接池实例多了连接数线性增长必须用 PgBouncer 或 MySQL Proxy 之类的连接池中间件来控制数据库连接总量。12. 最后分享一点个人体会这次调研做下来我最深的感受就是选型没有银弹。网上随便一搜就能看到各种技术文章的结论什么Uvicorn 吊打 GunicornDocker 就是性能杀手但真正落地到自己的项目里这些结论往往不适用。我的建议是每个项目上线前都按这套方法做一次简单的压测。不需要搞多复杂的工具一台压测机、一个 wrk、三个接口、三档并发花一个下午就能得到属于自己的性能基线数据。这个基线数据比任何网上文章都更有参考价值。另外一定要做好监控。我这次调研过程中踩的坑很多都是通过监控指标发现的比如 CPU 打满、文件描述符耗尽、数据库连接数暴增。没有监控压测数据再好也守不住生产环境的稳定性。最后再补一句部署方案选型要给自己留退路。我见过不少项目一上来就用 Docker 部署后面发现容器化排查问题太麻烦又迁回裸机部署折腾得不轻。先跑通最简单的方案确认业务稳定后再逐步引入更复杂的架构这个节奏我觉得最稳妥。个人博客和学习笔记持续更新中欢迎交流讨论。有什么部署性能方面的疑问也可以直接在评论区留言我尽量答复。