Docker 入门实战：后端服务第一次容器化，我踩过的 4 个坑

刚开始做后端开发时，我最怕听到一句话：“这代码在我机器上明明能跑。”环境不一致，是新手期最常见的翻车现场。后来我把自己的一个小服务第一次装进 Docker，才算真正理解容器解决的是什么问题：不是把代码搬个家，而是把代码和它依赖的整个环境一起打包，谁拿到都能原样跑起来。这篇就把完整过程和我踩过的坑写下来，给同样在入门的朋友参考。

一、先把服务准备好

示例是一个很小的 Python 服务，只有一个健康检查接口：

# app.py
from flask import Flask
app = Flask(__name__)

@app.route("/health")
def health():
    return {"status": "ok"}

if __name__ == "__main__":
    app.run(host="0.0.0.0", port=8000)

依赖写进 requirements.txt，只有一行 flask。注意服务监听地址要写 0.0.0.0，只监听 127.0.0.1 的话，容器外是访问不到的，这是我踩的第 0 个坑，还没正式开始就先翻了一次车。

二、写 Dockerfile 并构建运行

FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY app.py .
EXPOSE 8000
CMD ["python", "app.py"]

然后构建并运行：

docker build -t my-backend:1.0 .
docker run -d -p 8000:8000 --name my-backend my-backend:1.0
curl http://localhost:8000/health

返回 {“status”: “ok”}，容器化就完成了。整个过程不复杂，真正的坑都在细节里。

三、我踩过的 4 个坑

坑一：镜像大得离谱。 第一次我用了完整的 python:3.12 镜像，打出来 1GB 多。换成 slim 版本后，体积直接降到 200MB 以内。基础镜像能选小就选小，构建和拉取都会快很多。

坑二：改一行代码，依赖重装五分钟。 原因是 Dockerfile 里先 COPY 了全部代码再装依赖，代码一变，缓存就失效。把 requirements.txt 单独先 COPY、先安装，代码层排在后面，之后改业务代码时依赖层走缓存，构建只要几秒。

坑三：把配置写死在镜像里。 数据库地址、密钥这类东西绝不能写进代码再打进镜像，换个环境就要重新构建。正确做法是运行时用 -e 传环境变量，或者用 --env-file 管理，镜像只负责逻辑，配置交给运行环境。

坑四：容器一删，数据全没。 容器内的文件系统是临时的，日志、上传文件这类需要留存的数据，要挂载数据卷：docker run 时加 -v mydata:/app/data。想明白哪些数据要活得比容器久，是用 Docker 绕不开的一课。

四、写在最后

容器化的门槛其实不在命令多难，而在于把“环境也是交付物”这个观念立起来。先从一个小服务开始，跑通构建、运行、访问这条线，再回头收拾镜像体积、构建缓存、配置注入和数据卷这四个细节，一次完整的入门就完成了。后面无论是上 CI/CD，还是把服务部署到云服务器，都会顺很多。