最简可用C++应用Dockerfile应分离编译与运行：用多阶段构建，第一阶段用g++:12等完整镜像静态链接编译（加-static-libstdc++ -static-libgcc），第二阶段用alpine:latest或distroless/cc仅复制二进制并ENTRYPOINT指向它；避免在运行镜像中安装build-essential等冗余工具或动态链接兼容性问题。
怎么写一个能跑起来的 C++ 应用 Dockerfile
直接上最简但可用的路径：用 g++ 编译好二进制，扔进 alpine 或 debian:slim 基础镜像里，ENTRYPOINT 指向它。别用源码编译镜像当运行镜像，那是构建阶段的事。
常见错误是把 build-essential、cmake 全塞进最终镜像，结果镜像几百 MB，还带一堆没用的头文件和静态库；更糟的是在容器里现场 g++ main.cpp，一重启编译环境就丢。
- 编译和打包必须分离：本地或 CI 里用完整工具链编译出静态链接二进制（推荐），或确保动态依赖全打进镜像
- 优先用
FROM gcr.io/distroless/cc或alpine:latest，不是ubuntu:22.04 - 如果用了
std::filesystem或std::thread，GCC 11+ 默认需要libstdc++.so.6和libgcc_s.so.1，alpine用的是musl，不兼容——这时要么换debian:slim，要么加-static-libstdc++ -static-libgcc
示例（静态链接）：
FROM g++:12 COPY main.cpp . RUN g++ -static-libstdc++ -static-libgcc -o myapp main.cpp <p>FROM alpine:latest COPY --from=0 /workspace/myapp /usr/local/bin/myapp ENTRYPOINT ["/usr/local/bin/myapp"]
动态链接时怎么确认容器里缺哪个 .so
运行报错 error while loading shared libraries: libxxx.so.y: cannot open shared object file 是典型症状。别猜，进容器用 ldd 看。
但注意：alpine 没 ldd，得装 binutils，或者干脆换 debian:slim 镜像再试——省掉一层兼容性纠缠。
立即学习“C++免费学习笔记（深入）”；
- 在构建镜像前，先在同系统环境跑
ldd ./myapp，记下所有非/lib64/ld-linux-x86-64.so.2开头的依赖 - Ubuntu/Debian 镜像里用
apt-get install -y libxxx1（包名通常带数字 1） - 别复制
.so文件到/usr/lib手动硬凑——版本冲突、符号解析失败概率极高 - 如果依赖了 Qt、OpenCV 这类大库，建议用它们官方提供的 runtime 包，而不是自己编译安装
Docker build 时如何避免反复下载依赖（比如 Boost、fmt）
每次 git clone 或 wget 第三方库，不仅慢，还让镜像层失效，缓存全废。
根本解法：把依赖下载和编译提到多阶段构建的前置 stage，且把下载命令和解压/编译命令拆开——让「下载」这层尽可能稳定。
- 用
RUN curl -L https://... | tar -xzf - -C /deps不如分两行：RUN curl -L -o boost.tar.gz https://...+RUN tar -xzf boost.tar.gz -C /deps，前者可缓存，后者只要 URL 不变就不重跑 - Boost 这种带
bootstrap.sh的，别在RUN里连着执行./bootstrap.sh && ./b2 install，拆成两个RUN，避免 configure 失败导致整个 layer 白做 - 如果项目用
vcpkg或conan，把vcpkg install放在单独 stage，然后COPY --from=deps /vcpkg/installed /usr/local/vcpkg/installed
容器里调试 C++ 程序崩溃（SIGSEGV / SIGABRT）怎么办
默认的 slim/alpine 镜像没有 gdb、没 core dump 支持、没符号表——等于关灯修发动机。
线上只跑 stripped 二进制是对的，但调试镜像必须另建：加调试符号、开 core limit、带 gdb 或至少 addr2line。
- 编译时加
-g，链接时别加-s（strip）；发布镜像用objcopy --strip-debug单独剥离，留一份带符号的用于调试 - 启动容器加
--ulimit core=-1，并在容器内echo '/tmp/core.%e.%p' > /proc/sys/kernel/core_pattern - 崩溃后进容器跑
addr2line -e ./myapp -f -C -i 0x7fabc1234567（地址从日志或gdb core里取），比盲猜快得多 - 如果必须用
gdb，别往生产镜像里塞，起一个临时调试容器：docker run --rm -it --pid=container:myapp -v $(pwd):/dbg ubuntu:22.04 gdb /dbg/myapp /proc/1/root/tmp/core.myapp.123
真正麻烦的从来不是打包本身，而是 C++ 二进制背后那层隐式依赖：C++ 标准库 ABI、GLIBC 版本、内核 syscall 兼容性、甚至 CPU 指令集（比如本地编译用了 avx2，容器跑在老机器上直接 Illegal instruction）。这些不会报错“找不到文件”，只会静默崩掉。
