核心不是等构建失败再翻日志，而是提前预判、过程监控、分段验证：通过构建日志识别“Killed”信号，用dmesg确认OOM Killer介入，以--memory限制资源暴露问题，拆解RUN指令、添加内存检查与进程监控，并借助ccache、多阶段构建和JVM参数优化编译内存占用。
排查 RUN 指令在 Docker 构建阶段因依赖编译导致的内存溢出，核心不是等构建失败再翻日志，而是提前预判、过程监控、分段验证。
看构建日志里的关键信号
编译卡住、gcc/clang 进程被 kill、或出现 Killed（不是 segfault 或 timeout）——这通常是 OOM Killer 干的，不是程序崩溃。此时立刻查宿主机：dmesg -T | grep -i "killed process"，确认是否真被杀；free -h && cat /proc/meminfo | grep -E "MemAvailable|SwapFree"，看构建前可用内存是否已低于总内存 15%。
限制构建资源，暴露问题而非掩盖
别直接加内存，先用资源约束让问题复现更稳定、更快定位：
• docker build --memory=2g --memory-swap=2g -t app .（强制限制，避免耗尽宿主机）
• 若使用 BuildKit，启用 DOCKER_BUILDKIT=1 并加 --progress=plain，可看到每条 RUN 的实时内存占用估算
• 对 C/C++ 项目，在 RUN 中编译前加 echo "MemAvailable: $(awk '/MemAvailable/{print $2}' /proc/meminfo) kB"，把当时可用内存打到日志里
拆解 RUN 指令，隔离编译环节
把长链 RUN apt update && apt install ... && make && cp ... 拆成多个独立 RUN，每步后加检查：
• RUN make -j$(nproc) 2>&1 | tee build.log || (cat build.log && exit 1)
• 紧接着加一行：RUN ps aux --sort=-rss | head -3，确认是哪个编译进程吃内存最多
• 对 Java/Maven 项目，加 JVM 参数控制： RUN mvn clean compile -DargLine="-Xmx1g -XX:MaxMetaspaceSize=256m"
• 对 Python 编译扩展（如 Cython、numpy），设 export CC="gcc -O2 -fPIC" 避免调试符号膨胀
换轻量工具链或缓存中间产物
很多溢出源于重复全量编译（比如每次构建都重装 node_modules + rebuild native addon）：
• 用多阶段构建，把编译环境单独做 builder 镜像，只 COPY 编译好的二进制或 wheel 包
• 利用 CACHE FROM 或 BuildKit 的 cache mount 缓存 .m2、node_modules、target 目录
• C/C++ 项目考虑用 ccache：先 RUN apt install ccache，再 RUN export PATH="/usr/lib/ccache:$PATH" && make -j$(nproc)
