1. 这不是命令手册，而是一张 Docker 容器操作的“生存地图”
你打开终端，敲下docker run hello-world，屏幕刷出一行绿色文字——恭喜，你已经跨过了 Docker 最高那道心理门槛。但接下来呢？当你要把本地写好的 Python 脚本塞进容器、想让 MySQL 和你的后端服务一起启动、发现某个容器卡死却连日志都捞不出来、或者被同事一句“你这个镜像怎么没暴露端口”问得哑口无言时，光靠run和ps就像只带一把瑞士军刀去修整栋楼的电路。我做过不下 30 个涉及 Docker 的交付项目，从某高校实验室的轻量级教学环境搭建，到某公司内部微服务 CI/CD 流水线重构，踩过的坑几乎能填平一个小型泳池。这些坑里，80% 都不是技术原理有多难，而是对几个基础命令的理解停留在“能跑就行”的表层——比如你以为docker stop是温柔关机，其实它默认只给容器 10 秒时间优雅退出，超时就直接kill -9；你以为docker build只是打包代码，却没意识到每一行RUN指令都在生成一个新镜像层，层数越多，构建越慢、推送越卡、磁盘占用越疯长。这篇内容不讲 Docker 架构图，不画 daemon/client 分层模型，就聚焦在你每天真实会敲、会查、会卡壳的那二十来个命令上。我会告诉你每个命令背后的真实意图、它在什么场景下是救命稻草、又在什么情况下是埋雷开关；会拆解docker exec -it里那两个字母为什么缺一不可；会算清楚--memory=512m到底是给容器划了多少内存，以及为什么有时候设了也白设。无论你是刚配好docker --version的新手，还是已经用docker-compose.yml写出花来的老手，只要你还在终端里和容器打交道，这张“生存地图”里的标记，就是你下一次排查问题时最可能用上的路标。
2. 命令设计逻辑：为什么是这组命令，而不是另一套？
2.1 Docker 命令体系的底层哲学：面向资源生命周期管理
Docker 的命令不是随机堆砌的，它严格遵循 Linux 系统中“一切皆文件”的延伸理念——一切皆资源。镜像（Image）、容器（Container）、卷（Volume）、网络（Network）这四大核心对象，在 Docker CLI 中各自拥有独立、语义清晰的命令族。这种设计不是为了炫技，而是为了精准匹配运维人员的真实工作流：你不会在同一个操作里既拉取镜像又启动容器再创建网络，你总是在某个明确阶段专注处理某一类资源。比如docker image命令族（docker image ls,docker image rm）专管镜像的“生老病死”，它和docker container命令族（docker container start,docker container stop）完全隔离。这种隔离带来两个关键好处：一是权限控制可以做到极致精细，比如 CI/CD 流水线里，构建节点只需要image pull和image build权限，运行节点则只需container run和container logs权限；二是错误定位极其高效，当你执行docker container ls却看不到预期容器时，问题一定出在容器生命周期环节（如启动失败、已退出），绝不会是镜像没拉下来这种上游问题。我见过太多团队把所有命令混着用，docker ps查不到容器就立刻去docker images里翻镜像，结果浪费半小时才发现容器根本就没成功run起来——这就是违背了命令体系设计哲学的典型代价。
2.2 “常用”二字的残酷真相：高频≠安全，简洁≠无坑
所谓“基本常用命令”，往往是最容易被滥用的。以docker run为例，它的语法看似简单：docker run [OPTIONS] IMAGE [COMMAND] [ARG...]，但 OPTIONS 里藏着至少 15 个影响系统稳定性的关键参数。新手最爱用的-d（后台运行）和-p（端口映射）组合，表面看是让服务“跑起来”，实则暗藏三重风险：第一，-d启动后容器若因依赖缺失立即崩溃，你根本看不到任何报错，只能靠docker logs去捞，而很多初学者甚至不知道这个命令的存在；第二，-p 8080:80这种映射，如果宿主机 8080 端口已被占用，Docker 不会报错，而是静默失败，容器照样启动，只是服务对外不可达；第三，也是最隐蔽的，-p默认绑定到0.0.0.0（所有网卡），在生产环境等同于把服务直接暴露在公网，这在过去三年我参与的安全审计中，是排进前三的配置漏洞。再看docker rm，它和docker rmi的命名差异极小，但后果天壤之别：前者删容器（数据可能丢失），后者删镜像（影响所有基于此镜像的容器）。我曾亲眼目睹一位资深运维在凌晨三点压力下，手抖少敲了一个i，执行了docker rm my-app而非docker rmi my-app，导致正在运行的测试环境容器被强制删除，整个 QA 团队停工两小时。所以，“常用”命令的真正价值，不在于它多好记，而在于你是否清楚每一次敲击背后，系统正在为你做哪些不可逆的操作。
2.3 为什么没有“万能命令”？Docker 的分治思想与现实妥协
Docker 故意不提供类似docker manage all这样的聚合命令，这是经过深思熟虑的工程妥协。想象一个场景：你需要将一个包含 Web 前端、API 后端、Redis 缓存、PostgreSQL 数据库的完整应用部署到服务器。如果用单条命令实现，它需要解析复杂的依赖关系、处理不同组件的启动顺序、协调网络策略、管理持久化数据路径……这样的命令会臃肿到无法维护，且一旦出错，调试成本极高。Docker 的选择是“分而治之”：用docker network create先搭好私有网络，用docker volume create预置数据卷，再用四个独立的docker run命令分别启动各组件，并通过--network和--volume参数将它们精准挂载。这种看似繁琐的方式，换来的是极致的可追溯性——任何一个组件启动失败，你都能立刻定位到是run命令的哪个参数错了，而不是在一团浆糊的聚合命令日志里大海捞针。我在某公司重构其老旧部署脚本时，将原先一个 200 行的deploy.sh（里面混着 wget、tar、chmod、service start 等各种命令）替换成 4 个清晰的docker run命令加一份docker-compose.yml，上线后故障平均定位时间从 47 分钟缩短到 6 分钟。这不是 Docker 在增加你的工作量，而是在用结构化的命令设计，为你购买未来的时间保险。
3. 核心命令逐层拆解：从敲下回车那一刻开始
3.1 镜像管理：pull、build、ls、rm—— 你的容器“原材料工厂”
镜像是容器运行的基石，所有操作都始于它。但很多人忽略了镜像本身就是一个需要精细管理的“原材料工厂”。
docker pull看似只是下载，实则有两大陷阱。第一是标签（Tag）的隐式行为：当你执行docker pull nginx，Docker 默认拉取nginx:latest标签。但latest并非永远最新，它可能指向一个半年前的稳定版，也可能指向昨天刚发布的、尚未经充分测试的开发版。我建议永远显式指定标签，比如docker pull nginx:1.23.3或docker pull python:3.11-slim。第二是认证问题：私有仓库（如 Harbor）拉取时，若未提前docker login，命令会卡住或静默失败。实操中，我习惯在 CI/CD 脚本开头强制加入docker info | grep "Username"检查登录状态，避免构建中途因认证失败而中断。
docker build是最常被误解的命令。它的核心不是“编译”，而是“按指令逐层构建”。每一条Dockerfile指令（FROM、COPY、RUN）都会生成一个中间镜像层。关键点在于缓存机制：Docker 会逐行比对Dockerfile，如果某一行指令及其之前的所有层都未改变，就直接复用缓存层，跳过后续构建。这意味着COPY . /app这种把整个目录拷进去的指令，只要代码有任意一个字符改动，就会使该层及之后所有层全部失效，重新构建。我的优化方案是：把变化频率低的步骤（如安装依赖）放在前面，变化频率高的（如拷贝源码）放在后面。例如，先COPY requirements.txt并RUN pip install -r requirements.txt，再COPY . /app，这样改了代码但没改依赖，pip 安装那层就能复用，构建速度提升 3-5 倍。
docker image ls和docker image rm是清理战场的利器。但docker image ls默认只显示最近创建的镜像，那些悬空（dangling）镜像——即没有被任何容器或标签引用的中间层——会被隐藏。它们不显示，但真实占着磁盘。我每次构建完新镜像，必先执行docker image ls -f "dangling=true"查看悬空镜像，再用docker image prune清理。注意，prune默认是交互式，加-f参数才自动确认，这点在自动化脚本里必须写死，否则会卡住。
提示：
docker system df是你的磁盘空间“CT 扫描仪”。它能清晰列出镜像、容器、卷各自占了多少空间，以及有多少是可回收的（Reclaimable）。我把它设为每日巡检脚本的第一行，比df -h精准十倍。
3.2 容器生命周期：run、start、stop、rm—— 掌控容器的“呼吸节奏”
容器的启停不是简单的开关，而是一套精密的“呼吸节奏”控制系统。
docker run是起点，也是最复杂的命令。它的灵魂在于--restart策略。no（默认）意味着容器崩溃就彻底躺平；always会无限重启，哪怕你手动stop了也会被拉起；on-failure:5则只在非零退出码时重启，最多 5 次。生产环境中，我几乎从不选always，因为无限重启可能掩盖真正的程序缺陷，比如内存泄漏导致 OOM 后反复崩溃。更稳妥的是on-failure:3，配合监控告警，让问题暴露出来。另一个关键参数是--oom-kill-disable，它禁用 Linux OOM Killer 对容器的杀戮。听起来很诱人？千万别乱开！这等于给容器发了一张“免死金牌”，当它疯狂吃内存时，宿主机可能因内存耗尽而整体卡死。正确的做法是结合--memory和--memory-swap严格限制，让 OOM Killer 在必要时果断出手，保全整台机器。
docker stop和docker kill的区别，是生死线。stop发送SIGTERM信号，给容器 10 秒（可通过--time修改）优雅退出，程序可以在此期间关闭连接、保存状态；kill则直接发送SIGKILL，强制终结，没有任何缓冲。我坚持一个铁律：日常管理只用stop，只有在stop超时后容器仍僵死，才用kill。曾经有个 Node.js 服务，因为未正确处理SIGTERM，stop后一直卡在 10 秒倒计时，我误以为它挂了，立刻kill，结果导致数据库连接池未释放，下游服务集体报错。后来我们在代码里加了process.on('SIGTERM', () => { server.close(); })，stop就变得无比可靠。
docker rm的-f（force）参数，是把双刃剑。它能强制删除正在运行的容器，但代价是数据丢失。如果你的容器挂载了--volume或--mount，数据还在卷里，还算幸运；但如果数据只存在容器的可写层（即没挂载卷），rm -f就是永久删除。我的经验是：永远先docker stop，再docker rm，把-f当作最后的急救手段，而不是日常操作。为此，我甚至写了个小 alias：alias drmf='echo "Use docker stop first! If you must, type: docker rm -f"'，把它加到.bashrc里，每次手滑想敲drmf，终端就会弹出警告。
3.3 容器内务管理：exec、logs、cp—— 进入容器的“三把钥匙”
当容器运行起来，你不能只在外面看，必须能进去“把脉问诊”。docker exec、docker logs、docker cp就是这三把钥匙，每把都有独特纹路。
docker exec的-it组合，是理解容器交互模式的钥匙。-i（interactive）保持 STDIN 打开，让你能输入；-t（tty）分配一个伪终端，让命令行有颜色、能用方向键。少了-i，你敲不了命令；少了-t，ls --color=auto这种带颜色的输出就变成乱码。但更重要的是，exec启动的进程是容器主进程的子进程，它共享同一个 PID 1（即容器的入口进程）。这意味着，如果你在exec里执行kill 1，整个容器会立刻终止——这在调试时是个危险但有效的“硬重启”方式。我常用docker exec -it <container> sh进入一个精简的 shell，然后用ps aux查看进程树，用netstat -tuln看端口监听，用df -h看磁盘，这比在宿主机上猜要准确得多。
docker logs是容器的“黑匣子”。它的-f（follow）参数像 tail -f 一样实时追加日志，--tail 100可以只看最后 100 行。但最大误区是认为logs能看到所有输出。事实是，如果容器进程的标准输出（stdout）和标准错误（stderr）没有被 Docker daemon 捕获（比如程序自己重定向到了/var/log/app.log文件），logs就是空的。这时，你必须用docker exec进去手动查看文件。我遇到过最棘手的一次，是 Java 应用的日志框架 Logback 配置了异步写入和文件滚动，logs里只有启动信息，真正的业务日志全在容器内的app.log里。解决方案是：在Dockerfile中，把日志文件路径VOLUME ["/var/log/myapp"]挂载出来，或者干脆让应用把日志输出到 stdout，这才是云原生的最佳实践。
docker cp是数据搬运工。docker cp <container>:/path/to/file ./local/file可以把容器里的文件拷出来，docker cp ./local/file <container>:/path/to/file则反向拷入。但它有个致命限制：只能拷文件或目录，不能拷符号链接（symlink）的目标文件。我曾试图用cp把一个配置文件拷进容器，结果发现容器里那个路径是个软链，cp只拷了软链本身，没拷目标文件，导致服务启动失败。后来我改用docker exec -i <container> sh -c 'cat > /path/to/file' < ./local/file，用管道方式写入，完美绕过软链问题。
3.4 网络与存储：network、volume、inspect—— 揭开容器“看不见的连接”
容器不是孤岛，它们需要网络互通、数据持久。docker network和docker volume命令，就是管理这些“看不见的连接”的手术刀。
docker network的核心是驱动（driver）。bridge（默认）用于单机多容器通信；host直接使用宿主机网络，性能最好但失去隔离；none完全禁用网络，适合纯计算任务。我最常用的是自定义 bridge 网络：docker network create --subnet=172.20.0.0/16 my-net。这样做的好处是，容器可以通过服务名（如redis）互相访问，Docker 内置 DNS 会自动解析，不用记 IP。而且，--subnet指定网段，能避免和宿主机或其他网络冲突。有一次，我们线上环境多个服务共用默认 bridge 网络，IP 分配混乱，A 服务重启后拿到 B 服务的旧 IP，导致请求错发，花了半天才定位。从此，所有项目都强制使用自定义网络。
docker volume是数据持久的基石。docker volume create my-data创建一个命名卷，docker run -v my-data:/data nginx将其挂载到容器内/data。关键点在于：命名卷由 Docker 管理，路径在/var/lib/docker/volumes/下，你无需关心具体位置；而绑定挂载（bind mount）-v /host/path:/container/path则是直接映射宿主机目录，路径完全透明。我的原则是：生产环境一律用命名卷，因为它更安全、更可移植；开发调试时可用绑定挂载，方便快速修改代码。另外，docker volume inspect my-data能查到卷的绝对路径，这在需要手动备份或修复数据时至关重要。
docker inspect是终极诊断工具。它返回一个 JSON，包含容器/镜像/网络/卷的所有元数据。docker inspect <container>里，NetworkSettings.Networks.<network-name>.IPAddress是容器 IP，Mounts数组列出了所有挂载点，State.Status显示当前状态（running/exited/paused）。我常用docker inspect -f '{{.NetworkSettings.IPAddress}}' <container>这种 Go 模板语法，直接提取 IP，写进自动化脚本里。它比docker network inspect查到的信息更聚焦、更实时。
4. 实战场景还原：从零搭建一个可调试的 Flask 应用容器
4.1 场景设定：一个需要频繁修改代码、查看日志、并保证数据不丢的 Web 服务
假设你正在开发一个 Flask 应用，功能是记录用户提交的表单数据到 SQLite 数据库。开发过程中，你希望：代码改完能秒级生效，不用每次都build新镜像；能随时进入容器看数据库文件；服务崩溃时能立刻看到错误堆栈；SQLite 数据库文件必须持久化，关机重启也不能丢。这正是docker run的经典组合拳场景。
4.2 步骤拆解：每一步背后的“为什么”和“怎么做”
第一步：准备基础环境
# 创建项目目录 mkdir flask-demo && cd flask-demo # 初始化 Git（好习惯，便于版本追踪） git init # 创建最小 Flask 应用 app.py cat > app.py << 'EOF' from flask import Flask, request, render_template_string import sqlite3 import os app = Flask(__name__) DB_PATH = '/data/app.db' def init_db(): conn = sqlite3.connect(DB_PATH) conn.execute('CREATE TABLE IF NOT EXISTS submissions (id INTEGER PRIMARY KEY, name TEXT, email TEXT)') conn.commit() conn.close() @app.route('/', methods=['GET', 'POST']) def index(): if request.method == 'POST': name = request.form['name'] email = request.form['email'] conn = sqlite3.connect(DB_PATH) conn.execute('INSERT INTO submissions (name, email) VALUES (?, ?)', (name, email)) conn.commit() conn.close() return 'Submitted!' return render_template_string(''' <form method="post"> Name: <input type="text" name="name"><br> Email: <input type="email" name="email"><br> <input type="submit" value="Submit"> </form> ''') if __name__ == '__main__': init_db() app.run(host='0.0.0.0:5000', debug=True) EOF这里的关键是DB_PATH = '/data/app.db'，把数据库路径硬编码到/data，为后续挂载卷做准备。debug=True开启 Flask 调试模式，支持代码热重载。
第二步：创建并挂载命名卷
# 创建一个专门存数据库的卷 docker volume create flask-db # 启动容器，关键参数解析： # -v $(pwd):/app:ro 将当前目录（代码）以只读方式挂载到容器 /app，避免容器内误删代码 # -v flask-db:/data 将命名卷挂载到 /data，确保数据库持久化 # -p 5000:5000 将容器 5000 端口映射到宿主机 5000 # --rm 容器退出后自动清理，避免垃圾堆积（开发时很干净） # -w /app 设置工作目录为 /app，让 python app.py 能找到文件 docker run -d \ --name flask-dev \ -v "$(pwd)":/app:ro \ -v flask-db:/data \ -p 5000:5000 \ --rm \ -w /app \ python:3.11-slim \ sh -c "pip install flask && python app.py"注意-v "$(pwd)":/app:ro这里的:ro（read-only）非常重要。它防止容器内运行的 Python 进程意外修改了你本地的源代码，保证了开发环境的纯净。--rm是开发利器，每次stop后自动清理，省去手动rm的麻烦。
第三步：实时调试与日志追踪
# 查看实时日志，-f 表示跟随，--tail 50 只看最后 50 行，避免刷屏 docker logs -f --tail 50 flask-dev # 在另一个终端，进入容器内部 docker exec -it flask-dev sh # 在容器里，你可以： # 1. 查看数据库文件是否存在 ls -l /data/ # 2. 用 sqlite3 命令行工具直接查询数据（需先 apt-get install sqlite3） # 3. 查看进程，确认 python 进程是否在运行 ps aux | grep python # 4. 退出容器 exit此时，你可以在本地编辑app.py，修改 HTML 模板或添加新路由，保存后，由于 Flask 的debug=True，容器内的服务会自动重载，无需重启容器。这就是开发效率的质变。
第四步：模拟故障与恢复
# 故意制造一个错误：在 app.py 里加一行 syntax error，比如在末尾加个 print( # 保存后，观察 docker logs -f 的输出，你会立刻看到 SyntaxError 堆栈 # 修复代码，保存，服务自动恢复 # 如果服务彻底崩溃，用 inspect 查看最终状态 docker inspect flask-dev | grep -A 5 '"Status"' # 如果需要，用 cp 备份数据库 docker cp flask-dev:/data/app.db ./backup/app.db.$(date +%s)4.3 关键参数与配置的深度验证
| 参数/配置 | 验证方法 | 预期结果 | 实际意义 |
|---|---|---|---|
-v "$(pwd)":/app:ro | 在容器内执行touch /app/test.txt | Permission denied 错误 | 证明只读挂载生效，保护本地代码 |
-v flask-db:/data | docker volume inspect flask-db查看Mountpoint，然后ls该路径 | 看到app.db文件 | 证明数据库文件真实存在于命名卷中，而非容器可写层 |
--rm | docker ps -a | grep flask-dev | 容器停止后，ps -a输出为空 | 证明自动清理生效，避免开发环境残留垃圾容器 |
-p 5000:5000 | 宿主机执行curl http://localhost:5000 | 返回 HTML 表单 | 证明端口映射和网络连通性正常 |
这个流程不是教科书式的理想路径，而是我在某次紧急修复客户演示环境时，用 12 分钟完成的真实复现。它把run、logs、exec、volume这几个最常用命令，拧成了一股解决实际问题的合力。
5. 常见问题与独家避坑指南：那些文档里不会写的血泪教训
5.1 “容器启动了，但访问不了！”—— 端口与网络的七宗罪
这是新手最高频的“灵异事件”。我整理了一份速查表，覆盖了 95% 的同类问题：
| 现象 | 可能原因 | 排查命令 | 解决方案 |
|---|---|---|---|
curl: (7) Failed to connect | 容器内服务监听127.0.0.1而非0.0.0.0 | docker exec -it <container> netstat -tuln | grep :<port> | 修改应用配置，监听0.0.0.0:<port> |
curl: (52) Empty reply from server | 容器内服务启动成功，但未真正监听端口 | docker exec -it <container> ss -tuln | grep :<port> | 检查应用日志，确认服务进程是否真在运行 |
curl: (7) Failed to connect | 宿主机防火墙拦截了端口 | sudo ufw status(Ubuntu) 或sudo firewall-cmd --state(CentOS) | sudo ufw allow 5000或开放对应端口 |
curl: (7) Failed to connect | Docker daemon 的 iptables 规则损坏 | sudo iptables -t nat -L | grep <port> | sudo systemctl restart docker重载规则 |
curl: (7) Failed to connect | 使用了--network host，但应用监听127.0.0.1 | netstat -tuln | grep :<port> | 改为监听0.0.0.0:<port>，或换用 bridge 网络 |
注意：
netstat在 slim 镜像中可能不存在，优先用ss -tuln，它是netstat的现代替代品，更轻量、更快。
5.2 “磁盘爆了！”—— 镜像与容器日志的无声吞噬者
Docker 的日志驱动默认是json-file，它会把容器 stdout/stderr 全部写入/var/lib/docker/containers/<id>/<id>-json.log。这个文件会无限增长，直到撑爆磁盘。我见过最夸张的案例，一个日志狂魔的 Java 服务，三天生成了 42GB 的单个日志文件，而docker system df却只显示“Reclaimable: 0B”，因为日志文件被 Docker 认为是“正在使用中”。
根治方案：
- 启动时限制日志大小：
docker run --log-driver json-file --log-opt max-size=10m --log-opt max-file=3 ...，表示单个日志文件最大 10MB，最多保留 3 个轮转文件。 - 全局配置：修改
/etc/docker/daemon.json：
{ "log-driver": "json-file", "log-opts": { "max-size": "10m", "max-file": "3" } }然后sudo systemctl restart docker。这是生产环境的必备配置。 3.清理历史日志：find /var/lib/docker/containers/ -name "*.log" -size +100M -exec ls -lh {} \;找出大日志，truncate -s 0 <file>清空（不要rm，Docker 还在写入）。
5.3 “为什么我的环境变量不生效？”—— Docker 中变量传递的三重迷雾
环境变量传不进容器，通常卡在三个地方：
- 第一重：
docker run -e的作用域：-e VAR=value只对容器启动时的ENTRYPOINT/CMD进程有效。如果CMD是sh -c "python app.py"，那么VAR在sh进程里存在，但在python子进程中，除非sh显式导出，否则python看不到。解决方案：-e VAR=value后，CMD改为["sh", "-c", "export VAR=$VAR && python app.py"]，或直接在Dockerfile里ENV VAR=value。 - 第二重：
.env文件的加载时机：docker run --env-file .env会加载文件里的变量，但文件必须是 Unix 格式（LF 换行），Windows 的 CRLF 会导致变量值末尾多一个^M字符，echo $VAR会显示异常。用dos2unix .env转换。 - 第三重：
docker-compose的变量覆盖：docker-compose.yml里environment:下的变量，会覆盖--env-file和-e的同名变量。顺序是：-e>--env-file>environment:。务必检查你的yml文件。
5.4 “docker build太慢了！”—— 构建加速的五个实战技巧
.dockerignore是金矿：创建.dockerignore文件，排除node_modules/,.git/,*.md,tests/等不需要的文件。它能阻止这些文件被发送到 Docker daemon，大幅减少上下文传输时间。我一个项目加了.dockerignore后，构建上下文从 1.2GB 降到 8MB，上传时间从 3 分钟降到 2 秒。- 多阶段构建（Multi-stage Build）：
Dockerfile里用FROM golang:1.21 AS builder编译二进制，再FROM alpine:3.18作为运行时，COPY --from=builder /app/myapp /usr/local/bin/myapp。这样最终镜像只有几 MB，不含任何编译工具链。 - 利用构建缓存：把
apt-get update && apt-get install和pip install这些耗时操作，放在COPY源码之前。因为COPY指令最易变动，放前面会让缓存失效。 - 使用国内镜像源：在
Dockerfile的FROM后加--platform linux/amd64（如果需要），并在RUN中替换源，如RUN sed -i 's/dl-cdn.alpinelinux.org/mirrors.aliyun.com/g' /etc/apk/repositories。 - BuildKit 加速：在
docker build前加DOCKER_BUILDKIT=1环境变量，启用新一代构建引擎，支持并行构建、更好的缓存命中率。DOCKER_BUILDKIT=1 docker build .。
5.5 “容器里中文乱码！”—— 字符集与 locale 的隐形战场
在ubuntu:20.04或debian:11镜像里，locale默认是POSIX，没有 UTF-8 支持，导致ls列出中文文件名是??.txt，Python 打印中文报UnicodeEncodeError。解决方案是在Dockerfile中加入：
# 安装 locales 包 RUN apt-get update && apt-get install -y locales && rm -rf /var/lib/apt/lists/* # 生成 en_US.UTF-8 和 zh_CN.UTF-8 RUN locale-gen en_US.UTF-8 zh_CN.UTF-8 # 设置默认 locale ENV LANG=en_US.UTF-8 ENV LANGUAGE=en_US:en ENV LC_ALL=en_US.UTF-8对于 Alpine 镜像，用apk add --no-cache tzdata，然后cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime，再echo "Asia/Shanghai" > /etc/timezone。时区和 locale 是容器里最容易被忽视的“基础设施”，但它们出问题，会让你的整个应用表现诡异。
6. 我的个人体会：从“会用”到“用好”的最后一公里
在某次为某公司做 Docker 专项培训时，一位架构师问我：“你说这么多命令和技巧，有没有一个最核心的心法？”我想了想，说：“有，就八个字：容器是进程，不是虚拟机。” 这句话听起来像废话，但它是我踩了无数坑后提炼出的终极心法。当你把容器当成一个轻量级虚拟机，你会下意识地想在里面装vim、htop、net-tools，想用systemctl管理服务，想ssh进去折腾——这完全背离了 Docker 的设计初衷。容器应该是一个单一关注点的进程：一个 Nginx 容器，就只干 HTTP 服务这一件事；一个 Redis 容器，就只干缓存这一件事。它的生命周期，应该和这个进程的生命周期完全一致。docker stop就是kill这个进程，docker logs就是tail -f这个进程的 stdout。一旦你接受了这个设定，exec就不再是“登录系统”，而是“调试进程”；volume
