优化Docker镜像内存占用需三步：选轻量基础镜像（如alpine或distroless）、用多阶段构建只保留运行文件、清理构建残留并精简启动逻辑，可降内存开销30%～60%。
直接从 Dockerfile 入手优化物理内存占用，核心是减少镜像体积、精简运行时依赖、控制启动行为——这三步做好，容器启动后的基础内存开销能降 30%～60%。
选轻量级基础镜像，砍掉一半基础开销
基础镜像决定容器的“体重起点”。Ubuntu/Debian 镜像通常带完整包管理器和 shell 工具，启动后基础内存占用 50MB～100MB；Alpine 镜像仅含 musl libc 和 busybox，同功能下只要 5MB～10MB。
- 优先用
alpine或distroless（如gcr.io/distroless/java17），避免运行时携带编译工具、文档、调试器等无用组件 - Java 应用慎用
openjdk:17-jdk（含 JDK 全套工具链），改用openjdk:17-jre-slim或 distroless 版本 - Node.js 应用可用
node:18-alpine，比node:18（Debian 基础）小 70% 以上
用多阶段构建，只保留运行必需文件
编译型语言（Go/Java/Node）常把构建环境打包进最终镜像，导致镜像臃肿、内存冗余。多阶段构建能彻底分离构建与运行环境。
minimax-mcp-docker版（适配极空间）
下载
MiniMax 图片理解 + 网络搜索 MCP 工具。适配 Docker 环境（极空间等），支持图片 OCR 识别、图像内容理解、网络搜索。API Key 安全存储在本地 credentials 文件，不暴露在代码中。
- 第一阶段用完整 SDK 镜像编译（如
golang:1.22），第二阶段用scratch或alpine拷贝二进制文件 - Java 项目可先用
maven:3.9-openjdk-17构建 JAR，再用openjdk:17-jre-slim运行，去掉 Maven、源码、.class 编译缓存 - 每阶段结束后自动丢弃中间层，避免
apt-get install的临时文件、包缓存残留
清理构建残留，防止“隐形”内存占用
Dockerfile 中未显式清理的临时文件，会固化进镜像层，不仅增大磁盘体积，还会在容器启动时被加载到内存页缓存中，间接抬高 RSS 占用。
-
RUN apt-get update && apt-get install -y xxx && rm -rf /var/lib/apt/lists/*—— 清理 APT 缓存 -
RUN npm install && npm prune --production && rm -rf package-lock.json node_modules/.cache—— 删除 dev 依赖与缓存 - 避免分多条 RUN 指令安装+清理：合并为单条命令，确保中间产物不保留在镜像历史中
精简启动逻辑，避免进程/线程空转
ENTRYPOINT 或 CMD 启动脚本若未做裁剪，可能默认拉起监控代理、日志轮转、健康检查服务等，每个额外进程都消耗几 MB 内存。
- 禁用非必要后台服务：如 Alpine 镜像中默认不启动 syslogd、crond；若不需要，不在启动脚本里调用
- Java 应用显式限制 JVM 堆内存：
java -Xms128m -Xmx128m -XX:+UseContainerSupport ...，启用容器感知（JDK8u191+/JDK10+ 默认开启） - Python 应用关闭不必要的调试器或 profiler，避免导入
tracemalloc或memory_profiler等开发期模块
