在docker-compose.yml中通过deploy.resources.limits.memory设硬上限（如6g）、reservations.memory设软预留（如3g），配合日志轮转、定期清理残留容器与网络，并用docker compose stats监控内存使用率，可有效防控内存泄漏与oom风险。
直接在 docker-compose.yml 中设置内存限制并配合监控与清理策略，是应对容器运行中内存泄漏最有效、最可控的方式。不依赖应用层修改，也能大幅降低 OOM 风险和系统不稳概率。
设置硬性内存限制与软性预留
在服务配置中明确声明内存上下限，让内核主动干预而非被动等待崩溃：
- 使用
deploy.resources.limits.memory设定硬上限（如6G），超出即触发 OOM Killer - 搭配
deploy.resources.reservations.memory设置软预留（如3G），帮助调度器预判资源需求 - 避免混用
mem_limit（旧式单机参数）和memory（Swarm 参数），统一用deploy.resources结构更稳定
启用日志轮转防止磁盘级“假泄漏”
Docker 默认将 stdout/stderr 写入无限增长的 JSON 文件，看似内存飙升，实为磁盘空间被日志占满导致 cgroup 统计异常：
- 在每个服务下添加日志驱动配置：
driver: "json-file"
options:
max-size: "10m"
max-file: "3"
- 该配置限制单个日志文件最大 10MB，最多保留 3 个，自动覆盖旧日志
- 无需重启 Docker daemon，重部署 compose 即生效
定期清理残留网络与僵尸容器
频繁 up/down 操作后，未回收的网络命名空间和悬空容器会持续占用内核内存：
- 执行
docker compose down --remove-orphans清理孤立网络和卷 - 添加定时任务清理历史容器：
docker container prune -f --filter "until=24h" - 检查残留网络：
docker network ls | grep "bridge\|compose"，手动移除无用网络
集成基础内存监控与告警
不靠人工盯屏，用命令快速定位异常增长的服务：
- 实时观察：
docker compose stats --no-stream --format "table{{.Name}}\t{{.MemUsage}}\t{{.MemPerc}}" - 重点关注
%MEM是否持续上升，且增长速率远超请求量变化 - 结合
docker inspect [container]查看MemoryStats.usage和limit的比值，确认是否逼近硬限
