C++单阶段Dockerfile易生成1GB+镜像，因编译需完整工具链（gcc、cmake等）且未清理apt/yum缓存；多阶段构建须拆为builder（含工具链）和runner（极简镜像），并静态链接或精准复制so依赖，同时builder中必须显式清理缓存与中间文件。
为什么C++项目用单阶段Dockerfile容易打出1GB+镜像
因为编译C++需要完整工具链：gcc、g++、cmake、make、boost头文件、openssl-dev等，这些在ubuntu:22.04或centos:7里加起来就占几百MB；更关键的是，RUN yum install ... && make && make install之后不清理缓存，/var/cache/yum或/var/lib/apt/lists会原封不动留在镜像层里——Docker分层机制决定了“删除”只是新增一层标记为deleted，实际体积不减。
C++多阶段构建必须拆成builder + runner两个明确阶段
builder阶段负责编译，runner阶段只运行，两者基础镜像不能混用：
- builder阶段用
ubuntu:22.04或centos:7这类带完整工具链的镜像，确保cmake、g++、pkg-config都能跑通 - runner阶段必须换极简镜像：
alpine:3.19（5MB）、debian:slim（60MB）或distroless/cc-debian12（无shell，约20MB） - builder阶段必须用
AS builder命名，runner阶段不能有AS，也不能出现任何RUN cmake或RUN make - 复制产物必须写死路径：
COPY --from=builder /usr/local/bin/myapp .，别用COPY --from=builder /usr/local .这种宽泛路径，否则会把整个/usr/local/include都拖进去
动态链接 vs 静态链接：选错直接让runner镜像膨胀3倍
C++默认动态链接，runner镜像必须装对应.so，比如libstdc++.so.6、libssl.so.1.1——这就逼你得在runner里RUN apt-get install -y libssl1.1 libstdc++6，体积立马涨到100MB+。解决办法只有两个：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 静态链接：在builder阶段加
-static标志，如g++ -static -o myapp main.cpp，这样runner可用scratch（0B）或alpine，但要注意某些库（如glibc）不支持完全静态链接 - 用
ldd myapp检查依赖，把缺失的.so手动COPY进runner，再RUN chmod +x，比装完整包管理器轻量得多 - 更稳的折中方案：用
debian:slim作runner，它自带基础glibc和ca-certificates，不用额外装，体积控制在60–80MB之间
builder阶段不清理缓存，多阶段也白搭
很多同学写了多阶段，结果镜像还是300MB+，问题出在builder里没做清理。这几个地方必须显式删掉：
立即学习“C++免费学习笔记（深入）”；
RUN apt-get update && apt-get install -y build-essential cmake && rm -rf /var/lib/apt/lists/*- 如果用了
conan或vcpkg，构建完要RUN rm -rf ~/.conan或RUN rm -rf /opt/vcpkg/installed - cmake生成的
build/目录必须在COPY前删掉：RUN rm -rf build/ && make install - 避免在builder里
COPY . .，改成先COPY CMakeLists.txt .再COPY src/ src/，防止.git或build缓存被误带入
最终镜像是否真瘦身，别光看docker images，要跑docker history your-image-name：runner阶段应该只有1–2层，每层不超过10MB；如果看到几百MB的层，说明某步COPY或RUN漏了清理。
