Docker Desktop 无全局 /dev/shm 配置界面，必须显式指定 --shm-size 或 shm_size；其常失效主因是 WSL2 内存限制及镜像挂载逻辑冲突，需配合 --mount、调高 WSL2 内存并实测验证。
直接说结论：Docker Desktop 本身不提供全局共享内存（/dev/shm）的默认值配置界面，必须通过 --shm-size 命令行参数、docker-compose.yml 或容器启动时显式指定 —— 否则所有容器都沿用 Docker 引擎默认的 64MB。
为什么 --shm-size 在 Docker Desktop 上经常失效？
这不是参数本身的问题，而是 Docker Desktop 底层运行在虚拟机（WSL2 或 Hyper-V）中，存在两层限制：
-
--shm-size只控制容器内/dev/shm的 tmpfs 大小，它不能突破宿主机（即 WSL2 VM）的可用内存上限 - 如果 WSL2 分配的总内存只有 2GB（Docker Desktop 默认值），而你给一个容器设了
--shm-size=4g，实际挂载仍会卡在可用内存边界，df -h /dev/shm显示的仍是接近 WSL2 剩余内存的值，而非你指定的 4G - 某些镜像（如
node:alpine）甚至会忽略--shm-size，因为 Alpine 的tmpfs挂载逻辑更严格，需配合--mount type=tmpfs,destination=/dev/shm,tmpfs-size=2g才可靠
如何验证容器的 /dev/shm 实际大小？
别只信启动命令，进容器实测最准：
- 执行
docker exec -it，看df -h /dev/shm Size列是否匹配你设置的值 - 若显示
shm 64M，说明--shm-size没生效，常见原因：镜像启动时已提前挂载/dev/shm（比如某些 Chromium 镜像自带初始化脚本），后续--shm-size被忽略 - 补救办法：强制覆盖挂载，用
--mount type=tmpfs,destination=/dev/shm,tmpfs-size=2g替代--shm-size，该方式优先级更高
Docker Desktop 下多容器共享同一块 shm 怎么做？
单靠 --shm-size 不行，它只为每个容器创建独立的 /dev/shm。要真正共享，必须绕过容器隔离，走宿主机中间层：
- 在 WSL2 中手动创建 tmpfs 挂载点：
sudo mkdir -p /mnt/wsl/shared-shm && sudo mount -t tmpfs -o size=2g tmpfs /mnt/wsl/shared-shm - 启动容器时统一挂载该路径：
docker run -v /mnt/wsl/shared-shm:/dev/shm ubuntu:22.04 - 注意：WSL2 的
/mnt/wsl/是跨发行版可见的，但该挂载在 WSL2 重启后丢失，建议写入/etc/wsl.conf或 WSL2 启动脚本固化 - 替代方案：使用
--ipc=container:让容器共享 IPC 命名空间，但仅对 System V 共享内存（shmget）有效，POSIX（shm_open）仍依赖/dev/shm内容一致性
Compose 文件里怎么安全配置 shm？
YAML 格式容易踩空格和单位陷阱：
- 正确写法（注意引号和单位）：
shm_size: '2gb'或shm_size: 2g（docker-composev2.20+ 支持无引号数字单位） - 错误写法：
shm_size: 2g（旧版 Compose 会当成字符串变量解析失败）、shm_size: 2GB（大小写敏感，必须小写g或m） - 若服务依赖 Chromium/Puppeteer，建议同时加
mem_limit: 4g，避免因 WSL2 内存不足导致/dev/shm实际分配缩水 - 生产环境强烈建议加健康检查：
healthcheck: test: ["CMD", "df", "-h", "/dev/shm"]，防止部署后才发现 shm 不足
最常被忽略的一点：Docker Desktop 的 WSL2 内存是硬上限，--shm-size 再大也得有物理内存兜底。调高前先改 .wslconfig 里的 memory=4GB，否则一切配置都是纸面数字。
