多阶段构建+tmpfs挂载可打造轻快服务镜像：选alpine或distroless基础镜像，编译与运行分离，仅保留必要组件；运行时挂载/tmp、/var/run等路径至tmpfs，并验证挂载生效及内存使用合理。
直接用多阶段构建 + tmpfs挂载组合，就能做出既轻又快的服务镜像。关键不是堆功能，而是让运行时只保留必要组件，并把高频临时读写引向内存。
选对基础镜像，从源头减负
别用 ubuntu:22.04 这类完整发行版做运行镜像。优先选 alpine 或 distroless：
- alpine:3.20：rootfs 不到 6MB，自带 busybox 和 apk，适合需要 shell 调试的场景
- gcr.io/distroless/static-debian12：真正零 shell、零包管理器，仅含运行时依赖，体积常低于 10MB
- 避免在最终镜像中安装 curl、vim、bash 等开发工具——它们不参与服务逻辑，却显著增大体积和攻击面
构建阶段剥离编译依赖
用多阶段构建把“编译”和“运行”彻底分开。以下是一个 Python Web 服务的典型结构：
- 第一阶段（builder）：用 python:3.11-slim 安装 pip、编译依赖（如 cryptography）、打包 wheel
- 第二阶段（runtime）：用 alpine:3.20 或 distroless 镜像，仅 COPY 编译好的 .whl 或二进制文件 + 依赖库
- 关键操作：RUN pip install --no-cache-dir --find-links /wheels --no-index -r requirements.txt，配合 .dockerignore 排除 __pycache__、.git、tests 等非运行文件
运行时挂载 tmpfs，定向加速敏感路径
镜像本身不存缓存，靠启动时挂载 tmpfs 把临时 I/O 引入内存。重点挂载这几类路径：
- /tmp：通用临时目录，所有应用默认写入点，建议 size=32m～64m
- /var/run：存放 socket、pid 文件，避免磁盘争抢，建议 size=16m
- /var/log/app：若应用支持日志重定向（如 Gunicorn 的 --access-logfile -），可将日志输出到 tmpfs，再由 sidecar 收集，避免落盘抖动
- 禁用 noexec,nosuid 是底线配置，防止恶意代码执行或权限提升
验证与压测：确认效果真实落地
光配了不等于生效。上线前必须验证两件事：
- 进入容器执行 mount | grep tmpfs，确认目标路径已挂载且显示 size=xxx，而非 defaults（表示未限制）
- 模拟高并发写临时文件（如用 wrk 压测并触发大量 session 写入 /tmp），监控宿主机 free -h 和 cat /sys/fs/cgroup/memory/docker/*/memory.usage_in_bytes，确认内存增长在预期范围内
- 容器 stop 后检查宿主机对应目录是否无残留——这是 tmpfs 正确工作的铁证
