答案是共享内存（/dev/shm）不足导致崩溃，典型表现为“No space left on device”、Use%=100%，常见于Headless Chrome、PostgreSQL等应用；需通过df -h /dev/shm验证，用--shm-size或shm_size配置扩容，Windows上无需调整WSL2 shm但需保障其内存充足。
windows 上 docker 容器因共享内存（/dev/shm）不足崩溃，典型表现是应用突然退出、日志里出现 “no space left on device”，尤其在运行 headless chrome、postgresql、selenium 或机器学习服务时高频发生。这不是系统总内存不够，而是容器内部的 /dev/shm 区域被写满——默认仅 64mb，远低于实际需求。
确认是不是共享内存问题
别急着调参数，先验证是否真卡在这儿：
- 进容器查使用率：
docker exec -it <容器名> df -h /dev/shm。如果显示Use% = 100%或Avail = 0，基本就是它了； - 看错误日志：Chrome 启动失败常带
Failed to create shared memory segment；PostgreSQL 可能报could not resize shared memory segment； - 注意区分：这和 OOM Killer 杀进程（日志含
Out of memory: Kill process）无关，也不触发容器内存限制告警。
临时验证：手动挂载大 shm 进去
不改配置也能快速试效果：
- 停掉原容器：
docker stop <容器名>； - 用大 shm 重启：
docker run -d --shm-size=512m --name myapp <镜像名>； - 再观察是否还崩溃。如果稳了，说明问题定位准确。
长期解决：按场景设对 shm 大小
别一刀切全设 2GB，结合用途合理分配：
- 普通 Web 服务（Nginx、Node.js）：保持默认 64MB 即可；
- Headless Chrome / Selenium：至少 256MB，多标签或高分辨率截图建议 512MB；
- PostgreSQL：生产环境推荐 512MB～1GB，尤其开启大量连接或 shared_buffers > 512MB 时；
-
Docker Compose 用户：在
docker-compose.yml对应服务下加一行：shm_size: 512mb； -
注意：
--shm-size=0无效，Docker 会忽略；单位写错（如512MB写成512Mb）也可能被静默降级为默认值。
Windows 特别提醒：WSL2 底层不影响 shm 设置
虽然 Windows 的 Docker 依赖 WSL2，但 --shm-size 是直接传给容器的 Linux namespace 的，和宿主机 WSL2 内存分配无关。你只需确保：
- WSL2 自身内存够用（任务管理器看“内存”使用率别超 90%），否则 Docker Desktop 进程可能被 Windows 杀掉——那连容器都起不来，更别说 shm 了；
- 不需要、也不能在 WSL2 配置里单独调
/dev/shm，那是容器启动时由 Docker daemon 动态挂载的。
