docker build 命令必须显式指定构建上下文路径，如 docker build -t myapp .，末尾的 . 表示以当前目录为上下文；若 Dockerfile 不在默认位置，需用 -f 指定路径；Windows 用户应统一使用正斜杠，且所有路径须符合 Linux 风格。
直接用 docker build 就行，Docker Desktop 本身不提供额外构建入口——它只是把本地 Docker daemon 图形化了，构建逻辑和 CLI 完全一致。
docker build 命令必须带 .（当前目录）
很多人卡在第一步：执行 docker build -t myapp 报错 “unable to prepare context”。这是因为 docker build 必须显式指定构建上下文路径，而 Dockerfile 默认就在当前目录下。
- 正确写法：
docker build -t myapp .（末尾的.表示“以当前目录为构建上下文”） - 如果 Dockerfile 不在当前目录，要用
-f指定路径，比如：docker build -t myapp -f ./docker/Dockerfile . - Windows 下路径分隔符用正斜杠
/或双反斜杠\，别用单反斜杠（CMD/PowerShell 会误解析为转义）
Dockerfile 中 COPY 和 WORKDIR 路径必须是 Linux 风格
哪怕你在 Windows 上写 Dockerfile，容器内运行环境是 Linux，所有路径都按 POSIX 规范处理。混用 C:project 或 ./srcmain.py 会导致构建失败或文件缺失。
-
WORKDIR /app✅（推荐绝对路径） -
COPY . /app✅（源路径是上下文内的相对路径，目标是容器内路径） -
COPY srcmain.py /app/❌（反斜杠在某些 shell 下被忽略，srcmain.py可能被误读） - Windows 用户建议统一用正斜杠：
COPY src/main.py /app/
构建失败时先看 docker build 输出的最后一段错误
Docker 构建是分层执行的，某条指令失败后，后续指令不会运行，但错误信息往往堆在最后几行，前面大量日志容易干扰判断。
- 常见真实报错：
ERROR: failed to solve: process "/bin/sh -c pip install -r requirements.txt" did not complete successfully: exit code: 1—— 说明RUN pip install这一步挂了 - 不是网络问题就是
requirements.txt文件没被 COPY 进来（检查.dockerignore是否误删了它） - 如果报
No module named 'xxx'，大概率是COPY没覆盖到对应文件，或者WORKDIR设置后pip install执行位置不对 - 用
docker build --progress=plain -t myapp .可以看到更清晰的逐层输出，方便定位哪一层崩了
构建完成后镜像自动出现在 Docker Desktop 的 Images 标签页
构建成功后，不需要手动刷新或导入——Docker Desktop 会实时监听 daemon 状态。但要注意：
- 镜像名带冒号（如
myapp:dev）才算打标签；只写myapp默认是myapp:latest - 如果你改过 Dockerfile 又重新 build，Docker Desktop UI 里可能还显示旧镜像的创建时间，实际是新镜像（验证：终端执行
docker images myapp看CREATED时间） - 想清理旧层节省空间？运行
docker builder prune（清理构建缓存），不是docker system prune（会删掉你正在用的容器卷）
最常被忽略的一点：构建上下文（即 . 所指的目录）会被整个打包上传给 Docker daemon，里面任何没被 .dockerignore 排除的文件都会参与构建——哪怕是个 2GB 的 node_modules 或 __pycache__，都会拖慢构建、浪费内存、甚至触发超时。动手前务必配好 .dockerignore。
