镜像这个词，对用过 Docker 的人来说既熟悉又陌生。熟悉的是天天 docker pull、docker run，陌生的是镜像到底怎么存、怎么传、怎么管理，很多人其实一直没搞透。我在实际项目里踩过不少镜像相关的坑，从镜像仓库选型到私有仓库搭建，从构建缓存优化到镜像瘦身，这里头门道确实不少。这篇内容就把镜像和镜像仓库这摊子事从头到尾梳理一遍，希望对刚入门的朋友和用了一段时间但还没系统了解的朋友都有帮助。
1. 整体思路拆解：先把镜像和镜像仓库的关系理清楚
1.1 镜像到底是什么，和容器有什么区别
很多初学者容易把镜像和容器混为一谈，其实一句话就能说清：镜像是静态的文件系统快照加元数据的集合，容器是镜像运行起来之后的动态实例。打个比方，镜像就像你电脑里装的一个"安装包"，容器则是这个安装包解压运行后正在使用的软件进程。同一个镜像可以同时创建多个互不干扰的容器，每个容器有自己的读写层，删掉容器也不会影响镜像本身。
这里有个关键点值得展开说：镜像的分层结构。Docker 镜像不是一个单一的大文件，而是由多层只读层堆叠而成。每一层对应 Dockerfile 里的一条指令，比如RUN、COPY。这种分层设计最大的好处是层复用——多个镜像如果共享底层，磁盘上就只存一份。比如你基于同一个基础镜像构建了十个业务镜像，底层那几层大家共用，实际占用空间远小于十份完整镜像之和。
还有个实用的冷知识：镜像分层也是 pull 速度快的根本原因。第二次拉取相同底层的镜像时，已经存在的层会直接跳过，只下载新增的层。这就是为什么你 pull 一个新镜像却提示"Already exists"的层加速。
1.2 镜像仓库在 Docker 体系里的位置
镜像仓库，英文叫 Registry，承担的角色就是存储和分发镜像的服务器端组件。Docker 的镜像分发模型可以简单理解为：客户端（Docker CLI）通过 daemon 向 Registry 发起 pull（拉取）或 push（推送）请求。官方默认的公共仓库是 Docker Hub，但生产环境里基本不会直接用公共仓库，因为网络、安全、合规、性能都不好控制。
按我的实践经验，镜像仓库的技术栈可以从三个维度选型：
- 规模维度：单机小团队用 Registry 2.0 就够了；几十台机器以上建议用带认证和 UI 的 Harbor；上 Kubernetes 的集群基本离不开 Quay 或企业版的 Harbor。
- 安全维度：是否需要对镜像做漏洞扫描？是否需要镜像签名？是否需要基于角色的访问控制（RBAC）？这几个问题直接决定选型上限。
- 运维维度：团队有没有专职运维？如果就一两个人，别选太重的东西，简简单单的 Registry + Nginx 认证可能比高大上方案更省心。
1.3 Docker Hub 与私有仓库到底怎么选
很多团队一上来就打算自建仓库，我反而建议你先想清楚：你的镜像是不是真的涉及敏感业务？如果只是个人学习、开源项目用，Docker Hub 免费版完全够用，拉取公共镜像也最方便。但凡是公司内部业务、数据库、代码编译产物这些，坚决不能放公共仓库，这一点没有商量余地。
还有第三个选择经常被忽略：用云厂商的镜像仓库服务。如果你本身业务就在某个云平台上，直接用他们提供的容器镜像服务通常比自己搭建省太多事。自带内网加速、免运维、高可用，成本折算下来往往比自建划算。自建仓库适合的场景更多是：纯内网环境、数据合规要求严格、或者云资源本身不在主流云平台上。
我的建议是按这个思路走：个人学习用 Docker Hub，云上业务用云厂商托管仓库，强隔离内网环境自建 Harbor，数据极其敏感的离线环境用最简 Registry 打底自己包一层认证。
2. 核心镜像操作解析：从拉取到推送的每一步
2.1 拉取镜像的原理与参数细节
docker pull是接触最多的命令，但背后的行为很多人没仔细抠过。拉取时 Docker 会先和 Registry 通信，确认镜像是否存在、有哪些层、每层的校验值是多少，然后一个个层拉下来存到本地存储驱动里。拉取中途断网了怎么办？Docker 会保留已下载的层，重新执行 pull 时从断点继续。这个机制在生产环境意外中断时非常实用。
关于镜像标签，我见过太多人踩的坑：只拉取不指定 tag，永远默认是 latest。latest 标签本身是浮动的，同一个 tag 可能今天和昨天指向不同镜像。生产环境如果依赖 latest，每次部署等于赌运气。正确的做法永远是明确 tag，而且要建立版本规范，比如1.2.3、release-2024.08.15、sha256-xxxx这类可追溯的标签体系。
这里额外提一个参数：docker pull --platform。如果镜像本身做了多架构打包（manifest list），你可以在 pull 时指定要拉取哪种架构的版本，比如在 x86 机器上拉 arm64 镜像做交叉调试，这个参数很实用。
2.2 构建镜像的两种方式和缓存机制
构建镜像有两套思路：传统的是写 Dockerfile 然后docker build，新版则推荐docker buildx配合 BuildKit。BuildKit 比传统构建强在哪？并行执行多个构建步骤、更好的缓存复用、支持构建时挂载和密钥管理。我在实际项目中把构建效率提升了两倍多，靠的就是 BuildKit 的缓存机制。
Dockerfile 指令顺序对缓存命中影响巨大。由于每层缓存是否失效取决于这一层指令是否发生变化，变化越频繁的指令越要往后放。比如，先COPY requirements.txt，再RUN pip install，这样依赖文件不变时，即使后面源码频繁改动，依赖层也能命中缓存。如果反过来先把整个项目目录 COPY 进去再安装依赖，那源码一改，依赖层就全部失效，每次都重装依赖，耗时成倍增长。
构建缓存还有一个值得注意的细节：COPY指令会计算被复制文件的校验和来决定缓存是否失效，但.dockerignore控制着哪些文件参与这个计算。如果.dockerignore没写好，把本地的一些临时文件、节点模块、编译缓存打进上下文里，不仅构建慢，还会频繁导致缓存失效。
2.3 推送镜像时必须要做的三件事
docker push看似简单，但推到仓库之前有三件事我是必做的：
第一，打标签的正确姿势。要把镜像推到某个仓库的某个路径下，镜像名必须带上仓库地址。比如 Hub 上的alpine实际完整地址是docker.io/library/alpine，自建仓库则形如registry.example.com/project/app:1.0.0。docker tag不是复制，只是给同一个镜像加引用，这理解清楚了就明白为什么 tag 操作秒完成。
第二，推送前先跑一遍镜像做冒烟测试。这步看起来多余，但救过我太多次了。本地构建的镜像在开发机上是好的，推到仓库再被生产拉取后，有时候就出问题。原因很多：架构差异、环境变量没注入、时区设置之类的。推送前docker run --rm跑一遍，做一次基础功能验证，能挡住大部分低级问题。
第三，确认认证状态。推送到私有仓库前先docker login。很多人会遇到明明登录过，过几天就 401 的问题。Docker 的凭证默认只存在~/.docker/config.json，但只要配置了 credential helper，通知你不会忘。生产环境的 CI 建议用专用机器人账号，别拿管理员账号直接配置到流水线里。
2.4 镜像的导入导出与离线分发
内网环境没法直接 pull 公共镜像，这时候docker save和docker load就是救命工具。docker save会把镜像所有层打包成一个 tar 文件，可以复制到 U 盘或通过内网传输工具拷到离线服务器上，再docker load导入。
这里有一个容易被忽视的性能细节：docker save支持--output参数直接输出到文件，也支持通过管道接gzip压缩。实操建议是先 save 再单独压缩，不要直接管道压，因为 Docker 输出的 tar 本身没压缩，选择压缩方式更灵活。比如：
docker save myapp:1.0.0 -o myapp.tar gzip myapp.tar # 传输后 gunzip myapp.tar.gz docker load -i myapp.tar我还建议保存时连同 tag 信息一起保留，导入后镜像名、tag 都是完整的。如果目标是离线导入到另一台机器并且后续要推送到他们的私有仓库，先docker tag改好目标仓库地址再 save，可以省掉导入后再改名的步骤。
3. 镜像仓库的搭建与运维实操
3.1 最简私有仓库：一行命令启动 Registry
如果只是临时测试或者内网小规模使用，官方 Registry 镜像是最快的路径，一条命令就能起一个不带认证的仓库：
docker run -d \ -p 5000:5000 \ -v /data/registry:/var/lib/registry \ --name registry \ --restart=always \ registry:2就这么简单，一个私有仓库就活了。往里面推镜像时注意，本机 daemon 默认只允许 HTTPS 仓库访问，HTTP 的私有仓库需要在/etc/docker/daemon.json里加上"insecure-registries": ["192.168.1.100:5000"]并重启 Docker。这一步是新手最容易卡住的坑，报错通常是http: server gave HTTP response to HTTPS client。
但这种裸 Registry 没有任何认证和权限控制，任何人只要能访问到这个端口就能拉取和推送镜像。所以只适合内网开发环境，绝不能直接暴露到公网。我见过有团队把裸 Registry 挂在公网服务器上，没几天就被塞满了挖矿镜像，这个教训值得记一下。
3.2 带认证的仓库：Nginx 反向代理 + Registry
要给 Registry 加上最基础的认证，最常见的方案是 Nginx 做 TLS 终止和基本认证。这个组合的好处是组件都是通用的，出了问题好排查。基本认证的账号文件用htpasswd生成：
# 安装 apache2-utils 后 htpasswd -Bc /etc/nginx/.htpasswd adminNginx 配置里核心的部分是把/v2/路径转发给 Registry 服务，并在 location 块里加auth_basic认证。启动 Registry 容器时要注意挂载数据卷的持久化，还有REGISTRY_STORAGE_DELETE_ENABLED这个环境变量，默认不开启删除功能，不设置的话即使调用删除 API 也只是软删除，磁盘空间不会被回收。
这套方案和裸 Registry 的核心区别就是多了认证层，镜像本身还在 Registry 里，但没登录就拉不到了。实际使用中 Nginx 层还能顺手做访问日志、限流、TLS 证书管理，对小型团队来说是性价比最高的方案。
3.3 企业级方案：Harbor 的核心价值
团队规模上来之后，裸 Registry 加 Nginx 就有点跟不上了。Harbor 是目前国内最主流的企业级镜像仓库方案，它比简单 Registry 多了几样关键能力：
RBAC 权限控制：项目粒度隔离，开发只能拉取，运维能推送，管理员能删镜像。多团队共用一套仓库时，这个能力直接决定你晚上能不能睡好觉。
镜像复制：支持跨仓库同步，常见用法是把外网拉下来的基础镜像同步到内网 Harbor，或做多机房的双向复制。这个功能让"公网拉镜像再转内网"变成自动化流程。
漏洞扫描：基于多引擎识别镜像的已知漏洞。扫描报告可以直接看到某个镜像存在的高危 CVE 数量，即使生产环境来不及修复，至少知道风险在哪里。
内容签名：用 cosign 对镜像做数字签名，部署前验证签名，确保你拉取到的镜像是发布时那个，没被篡改。
Harbor 的部署也比较简单，有在线安装器和离线包两种方式。离线包适合内网环境，安装的时候会检查 docker、docker-compose 版本，按它提示来就行。吃配置方面，建议至少 4 核 8G 起步，因为暴露了数据库、Redis、多个组件。
3.4 仓库存储的空间管理
镜像仓库跑久了，最突出的运维问题是磁盘空间爆炸。Registry 的存储后端支持本地文件系统、S3、Swift等对象存储，但无论哪种，镜像只增不减，空间管理是个持续的活。
有几个实用的维护技巧：
- 定期清理无 tag 的悬空镜像（
docker image prune负责本地，仓库层需要调 API 删除）。 - 设置仓库的垃圾回收机制，Harbor 里可以做定时清理任务。
- 给仓库存储挂独立磁盘和独立监控，设置空间水位告警，别等满了再处理。
- 有条件的话，把存储切到对象存储后端，容量弹性大得多。
我踩过的一个真实的坑是：某个运行的容器进程一直在写日志，把容器读写层撑爆了，整个节点 disk 打满，docker 直接拒绝干活。后来养成了一个习惯：给每个容器设置日志轮转，在 daemon.json 里配log-opts的max-size和max-file，这远比事后清理来得重要。
4. 镜像瘦身与构建优化经验
4.1 镜像为什么越来越大
很多项目镜像从 1G 起步，还一直往上涨。根本原因分三类：基础镜像选得大（比如 ubuntu 换 alpine 能缩一半以上）、构建过程没清理中间产物、构建上下文本身太大。我曾经把一个 1.8G 的 Python 项目镜像瘦到 250M，光换基础镜像就省掉了 60% 的体积，再改掉几行 Dockerfile 就降到了 250M。
4.2 基础镜像选型的实战策略
选择基础镜像的原则是：能小则小，能官方则官方，能固定版本就固定版本。Python 项目优先python:3.12-slim或alpine变体，Go 项目直接考虑scratch或distroless，Java 项目用eclipse-temurin-jre而不是完整 JDK 镜像。
但镜像小不等于万事大吉，alpine 的 musl libc 有时候会带来诡异的兼容问题，比如某些依赖了 glibc 特性的编译产物跑不起来。我的建议是先用 slim 版本保证兼容性，实在不行再换成 alpine，用体积换稳定，别一上来就追求极致最小化。
4.3 多阶段构建的正确打开方式
多阶段构建是镜像瘦身的核心手段。核心思路就是：用一个大而全的镜像完成编译，再把编译产物复制到干净的小镜像里。
拿一个 Go 服务举例：
# 第一段：构建阶段 FROM golang:1.22 AS builder WORKDIR /app COPY go.mod go.sum ./ RUN go mod download COPY . . RUN CGO_ENABLED=0 go build -ldflags="-s -w" -o server . # 第二段：运行阶段 FROM alpine:3.20 RUN apk add --no-cache ca-certificates tzdata WORKDIR /root/ COPY --from=builder /app/server . EXPOSE 8080 ENTRYPOINT ["./server"]构建产物只有最终阶段的内容，编译器、源码、依赖全都被留在了第一个阶段。这种方式既保证了构建过程的灵活性，又保证了运行镜像的干净。-ldflags="-s -w"能去掉调试信息进一步缩小二进制体积；CGO_ENABLED=0则确保编译出来的二进制不依赖动态链接库。
4.4 构建缓存与层合并的技巧
构建缓存能让重复构建的耗时大幅降低，但使用不正确反而会拖慢。除了前面说的指令顺序之外，还要注意COPY . .这种炸弹指令。如果你把整个项目目录复制进去，任何文件的改动都会让这一层以及之后的层全部失效。正确的做法是按需精确复制，比如：
COPY requirements.txt ./ RUN pip install --no-cache-dir -r requirements.txt COPY src/ ./src/依赖层只在requirements.txt变化时重建，源码层随便改都不影响依赖缓存。这个细节在大项目里的效率差距非常明显，依赖安装动辄几分钟到十几分钟，缓存命中一次就省下这笔时间。
关于层合并还有一个细节：Dockerfile 中每条指令都会产生一层，过多的层会拖慢构建和拉取。可以用&&把多条 shell 命令合并到一条RUN里，比如安装软件、清理缓存放在一起，既减少层数，又避免把临时文件留在镜像里。
5. 镜像安全与合规
5.1 镜像来源安全
镜像安全最薄弱的环节往往是来源。公共 Hub 上的镜像鱼龙混杂，同名镜像可能是冒充官方的高仿版本。拿基础镜像来说，下载量巨大、更新时间久远这些信息可以作为参考，但更可靠的判断标准是看是否有官方认证标识，以及 Digest 是否与官方公告一致。
这里我要强调一种更可落地的方案：所有基础镜像统一从几个可信的官方源拉取，然后打上自己的 tag 推到私有仓库固化。生产环境只从私有仓库拉取，禁止直接 pull Hub 的公共镜像。这样即使公共仓库上的镜像某天出现问题，你的固化和已验证的版本也不受影响。
5.2 漏洞扫描与修复闭环
镜像漏洞扫描不是跑一次就算完，而是要形成一个闭环：扫描发现漏洞、评估受影响镜像、修复更新、重新扫描验证、推进新版本部署。Harbor 自带的扫描器可以定期扫全部镜像，不漏掉新增的那几个。扫描发现漏洞后，根据漏洞等级和镜像的实际运行情况排优先级：
- 被公网访问的服务 > 内部业务 > 纯内部工具镜像
- 高危漏洞 > 中危漏洞 > 低危漏洞
修复的思路通常是升级基础镜像和依赖版本，重新构建推送，并在下一轮部署中替换旧镜像。反复修补同一镜像不是好习惯，应该做的是重建新版本镜像并淘汰旧版本。
5.3 Dockerfile 安全写法
镜像安全能不能在前端就堵住，很大程度上取决于 Dockerfile 怎么写得。几个高频的安全禁忌：
- 禁止在 Dockerfile 里硬编码密钥、密码、token。构建后的每一层都会保留这些信息，哪怕之后的层里删掉，底层历史里依然能挖出来。
- 运行容器不要用 root 用户。在 Dockerfile 末尾用
USER nobody或创建一个低权限用户。 - 只暴露必要的端口，不要随手
EXPOSE 8888。 - 构建时设置
ENV不要带敏感信息，像数据库密码这些应该通过运行时以密钥文件或环境变量的方式注入。 - 有网络下载动作的
RUN，考虑通过代理或缓存服务控制，避免在构建过程中访问外部不可信地址。
5.4 私有仓库的访问控制最佳实践
私有仓库不管用什么方案实现，访问控制都值得认真对待。我强烈建议至少做到这几点：
- 仓库绑定域名并强制走 HTTPS 证书，禁止用裸 IP + HTTP。
- 账号最小权限原则，开发账号只读权限、运维账号可写、管理员单独一个。
- 定期轮换账号密钥，特别是在人员变动的时候。
- 推送删除等敏感操作要记录审计日志，Harbor 里可以做，裸 Registry 可以靠 Nginx access log。
如果仓库暴露在公网，务必在防火墙上限制来源 IP，或者加 WAF 防护。镜像仓库被攻破后，攻击者可以直接往你的生产集群塞恶意镜像，这个灾难是毁灭级的。
6. 常见问题排查与避坑实录
6.1 常见报错对照速查表
把我在项目里遇到的高频问题整理成一张表，方便直接对着排查：
| 报错信息 | 常见原因 | 解决办法 |
|---|---|---|
http: server gave HTTP response to HTTPS client | 仓库是 HTTP 但 daemon 默认走 HTTPS | 配置insecure-registries或升级仓库为 HTTPS |
unauthorized: authentication required | 未登录或凭证失效 | 重新docker login，检查账号权限 |
manifest unknown | tag 不存在或镜像被删除 | 确认 tag 拼写、查询仓库列表 |
no space left on device | 磁盘空间耗尽 | 清理悬空镜像和日志，扩容存储 |
dial tcp: lookup xxx on x.x.x.x:53: no such host | DNS 解析失败 | 检查网络、DNS 配置，或改用 IP 访问 |
denied: requested access to the resource is denied | 推送权限不足 | 检查账号是否有该仓库写入权限 |
failed to push: tag does not match | 镜像名没带仓库地址 | 重新docker tag成完整地址格式 |
image pull access denied | 仓库不存在或账号无权访问 | 确认仓库路径，检查私有仓库认证状态 |
6.2 镜像拉取慢的深层原因和加速方案
公共镜像拉取速度慢，绝大部分是网络链路问题。要么想办法用镜像加速器，要么走内网私有仓库做中转，要么直接在本地网络条件好的环境拉下来再 save/load 传过去。
镜像加速器实际的原理就是一个代理层，它从 Docker Hub 上拉取镜像并缓存到你自己的网络里。配置方式是在 daemon.json 里加registry-mirrors参数。但注意，镜像加速器只对公共仓库的一部分生效，如果镜像本身在某个特殊仓库路径下，加速器不一定能覆盖，这时候用内网私有仓库转存反而更快。
还有一个经常被忽略的点：如果你在云服务器上拉取镜像慢，可能是云厂商自身的公共镜像源就没做好。很多云厂商都有自己的 Docker Hub 加速地址，配置上之后速度能提升一大截。
6.3 推送失败排查的真实案例
有个项目，同事反馈往 Harbor 推镜像总是报blob upload unknown。这问题表面看是层上传中断，底层原因多种多样——网络不稳、代理干扰、存储后端的问题都可能导致。
当时排查的顺序是：先从 client 测连通性，telnet 仓库端口通不通；再确认是不是证书问题，手动 curl 一下带认证的 API；然后看 Harbor 后端的存储日志，检查对象存储访问是否异常。最后定位到是对象存储连接超时导致大层上传中断。解决办法是把对象存储的超时时间调大、网络链路加固。
这个案例给了一个方法论：排查网络问题不要只盯客户端，仓库服务端和存储后端都要看，镜像上传是一个端到端链路，任何环节出问题都会表现为客户端报错。
6.4 清理镜像时的保留与删除策略
清理镜像是运维必做的日常。本地机器上，docker image prune -a会删除所有未被容器使用的镜像，听起来很爽，但如果机器上刚好有某个镜像稍后要用再拉一遍，反而浪费时间。我的做法是手动筛选：列出镜像按创建时间排序，把超过 30 天且运行环境中不再出现的旧版本删掉。
仓库层面，需要调用 Registry API 删除。Harbor 有 UI 操作，裸 Registry 要手动调 API：
# 删除某个 tag 的 manifest（Harbor 示例） curl -u "用户名:密码" -X DELETE "https://harbor.example.com/api/v2.0/projects/项目名/repositories/镜像名/artifacts/版本号"删除后还要触发垃圾回收，否则空间不会被释放。Harbor 的垃圾回收可以在 UI 里开启定时任务，裸 Registry 需要手动对存储目录执行 GC。这块操作要格外小心，建议夜深人静业务低峰期做，做之前备份存储目录。
6.5 镜像 tag 管理的最佳实践
tag 管理是镜像生命周期里最容易被忽视又最容易被坑的环节。我见过团队镜像 tag 全是 latest，发布时根本不知道当前线上跑的是哪个版本，回滚只能靠猜。
推荐的做法是双重标签策略：push 时同时打语义化版本号 tag 和 commit 短哈希 tag。回滚时用版本号定位，排查问题时用 commit 哈希精确定位代码版本。
docker tag myapp:1.2.3 registry.example.com/project/myapp:1.2.3 docker tag myapp:1.2.3 registry.example.com/project/myapp:abc1234 docker push registry.example.com/project/myapp:1.2.3 docker push registry.example.com/project/myapp:abc1234另外，强烈建议给 tag 加不可变性策略，Harbor 可以配置 tag 保留规则和不可变规则。一旦某个 tag 被覆盖过，生产环境出现过莫名其妙的"配置没改但行为变了"的问题，排查方向就会多一个岔路，你说不清是代码问题还是镜像被覆盖。
7. 进阶扩展：镜像仓库体系在团队协作里的位置
7.1 镜像仓库和 CI/CD 流水线的衔接
镜像构建和推送是 CI/CD 流水线的核心环节。落地时我总结了一个比较顺的流程：代码提交触发流水线 → 自动构建并打上 commit 哈希标签 → 推送仓库 → 部署到测试环境 → 冒烟测试通过后打 release 标签 → 部署生产。
这个流程中，流水线推送镜像需要凭据，建议用专用机器人账号，权限限定到指定项目的推送权限，避免用个人账号引起权限管理混乱。之前也有团队把管理员账号直接写进流水线变量，人员变动后被迫全部重配，教训很深刻。
7.2 镜像不可变与版本追溯
镜像一旦推送后理论上不应该再修改，需要修复就去构建一个新版本。这样线上任何时刻运行的镜像内容都是确定的，出了故障能准确回溯到是哪个代码版本、哪个构建产物。这个理念在规模越大的团队价值越明显。
要做到不可变，需要两条硬规则：
- 仓库开启 tag 不可变，禁止覆盖同一个 tag。
- 删除操作要走审批流程，不能随手删。
7.3 多环境镜像管理
开发、测试、生产环境是否需要不同镜像？我的观点是镜像本身要尽量一致，差异交给配置管理。同一个镜像放在不同环境里，通过环境变量、配置中心、挂载文件注入不同配置，这才是正确姿势。因为如果各环境镜像构建逻辑不同，测试环境验证过的镜像和生产环境跑的不是同一个，测试就失去了意义。
镜像命名需要体现环境信息的话，用命名空间区分而不是改 tag。比如/project/app是公共的不分环境的镜像，tag 里带环境反而会导致镜像编排复杂化。当然这取决于团队规模，小项目简化处理没问题，但要清楚自己在简化什么。
聊到这儿发现，镜像仓库这件事本身不复杂，难的是把它嵌入团队工作流、踩过所有隐藏的坑之后总结出适合自己的一套规则。我最深的体会是：镜像上了生产别轻易改，tag 别乱用，仓库权限别图省事。这三个坑在初期看着不严重，等团队大了、系统多了、出错率上来之后，每一条都会让你后悔当初没认真对待。希望这篇内容能帮你把基础打扎实，少走一些我走过的弯路。
