Docker Compose 生产环境如何关闭 debug 模式提升性能

如果你的服务用 Docker Compose 部署在生产环境，但容器日志里满是调试信息，或者访问报错时把堆栈直接吐给用户，那多半是 debug 模式没关。关闭 debug 不只是为了好看，它能明显减少内存和 CPU 消耗，也避免把内部路径暴露出去。下面是我处理这类问题时的几个步骤，重点讲怎么确认、怎么改、以及改完之后要注意什么。

先确认服务是否真的开着 debug

在决定是否关闭debug之前，先要确认哪些服务正处于开发模式。最直接的方法是检查docker-compose.yml中服务的environment和command。比如Django服务常常通过DEBUG=True变量开启调试，Flask则依赖FLASK_DEBUG或app.debug属性。如果你发现容器日志里每个请求都打印访问记录、SQL查询甚至耗时的行级信息，或者通过docker exec进入容器后进程明显带有--debug、--reload之类的参数，那么基本可以断定该服务正在以debug模式运行。这类模式在开发时很顺手，但放在生产环境会显著增加内存和CPU开销，也会把内部路径暴露给客户端。

有一点需要提醒：如果服务是通过 Dockerfile 里的 ENV 设置 debug，光改 docker-compose.yml 可能没用，因为镜像构建时已经写死。所以检查时要把 compose 文件和 Dockerfile 一起看。

修改环境变量并重建容器

对于使用环境变量控制debug开关的框架，修改docker-compose.yml即可。例如将web服务的environment部分改为DEBUG=0或DEBUG=False，Java的Spring Boot可以设置SPRING_PROFILES_ACTIVE=prod，Node.js则设置NODE_ENV=production。修改后不要使用docker-compose restart，因为重启不会重新读取环境变量，必须执行docker-compose up -d，让容器被重新创建。如果服务依赖了额外的开发端口（比如Django的5000调试服务器），还需在ports映射中移除对应端口。改完后建议先在一台测试机跑一遍，确认业务功能正常再部署到生产。

举个例子，下面这段配置把 Flask 的 debug 关掉，同时用 gunicorn 启动：

services:
  web:
    image: your-app:latest
    environment:
      - FLASK_DEBUG=0
    command: gunicorn -b 0.0.0.0:8000 app:app
    ports:
      - "8000:8000"

这里的 key 是 FLASK_DEBUG，但不同框架会有差异，需要先确认你的启动脚本读取的是哪个变量。有些镜像用了 .env 文件，改的时候要注意 compose 会自动加载同目录下的 .env，别改错位置。

关闭后怎么验证生效

重建容器后，先用 docker ps 确认新容器已经运行，然后开一个终端执行 docker logs -f 服务名，再正常访问几个接口。如果之前的日志里每个请求都打印 SQL 或耗时信息，现在应该明显变少，只剩错误和警告。还可以找个不存在的路由访问一下，比如 curl -i http://localhost:8000/nonexistent 。debug 模式下通常会返回带堆栈的 HTML 或 JSON，关闭后只会看到通用的 404 或 500，响应体里不会出现文件路径和代码片段。注意这类探测操作不要在公网生产机直接做，放到预发布环境或者加访问控制，避免被其他人扫到。

另外，验证时要确认容器内进程确实没有 --debug 或 --reload 参数。用 docker exec 查看进程列表，比只看日志更直接。如果发现参数还在，说明启动命令里有硬编码，需要继续往下查。

关闭 debug 后的风险边界

关闭debug模式虽然能提升性能，但也会带来排查问题的风险，因为详细异常堆栈不再展示给客户端。因此，在关闭debug的同时，必须保证应用程序的错误日志被完整收集到容器stdout或挂载的日志文件。可以在docker-compose.yml的logging配置中设置json-file驱动并指定max-size和max-file，或使用logspout之类的工具转发到集中日志平台。另一方面，debug模式通常会启动代码自动重载，关闭后修改代码不会即时生效，这其实是好事，但部署流程要记得每次更新后重启容器。如果你依赖debug模式的交互式调试，请彻底停掉，不要留在生产环境。

容易被忽略的坑

实际部署时经常碰到环境变量已经设置成关闭，但服务仍在 debug 模式的情况。最常见的是镜像内的启动脚本或 Dockerfile 里硬编码了 --debug 参数，比如某些 Flask 官方镜像默认执行 flask run --debug，这种情况下命令行参数的优先级比环境变量高，你设置 FLASK_DEBUG=0 也没用。检查 Dockerfile 的 CMD 和 ENTRYPOINT，如果参数写死，就在 compose 的 command 里覆盖整个启动命令，或者干脆换成自己构建的精简镜像。另一个容易忽略的是把开发服务器直接当生产服务用，Flask 或 Django 自带的单线程服务器即使关了 debug，性能也远不如 gunicorn 或 uwsgi，建议在 compose 里就把启动命令改成这类 WSGI 服务器。