Docker Desktop 本身不提供图形界面配置容器用户组的功能，必须通过命令行参数或 Dockerfile 的 USER 指令实现；Windows/macOS 上的 Desktop 只是封装了 CLI，底层逻辑和 Linux 宿主机完全一致。
直接说结论：Docker Desktop 本身不提供图形界面配置容器用户组的功能，必须通过命令行参数或 Dockerfile 的 USER 指令实现；Windows/macOS 上的 Desktop 只是封装了 CLI，底层逻辑和 Linux 宿主机完全一致。
docker run --user 在 Docker Desktop 中怎么生效
在 Docker Desktop（Windows/macOS）中执行 docker run --user，行为和 Linux 宿主机一致，但要注意两个关键点：
- 宿主机文件系统（如 Windows 的 NTFS 或 macOS 的 APFS）不原生支持 UID/GID，挂载卷时权限映射由 WSL2 或 HyperKit 层模拟，
--user 1001:1001可能无法真实反映到宿主机路径属主上 - 若挂载的是 Windows 路径（如
-v C:\data:/app），Docker Desktop 默认以 WSL2 内部的root用户映射访问，此时--user对该卷的读写权限可能被忽略或静默失败 - 推荐做法：把数据目录放在 WSL2 文件系统内（如
/home/user/data），再挂载进容器，并确保该目录属主 UID/GID 和--user值一致
Dockerfile 里用 USER 指令设置启动用户是否在 Desktop 生效
完全生效，且是最推荐的方式。Docker Desktop 构建和运行镜像时，会严格遵循 Dockerfile 中的 USER 指令：
-
USER必须出现在CMD或ENTRYPOINT之前，否则后续指令仍以 root 执行 - 如果指定用户名（如
USER appuser），该用户必须在镜像中已存在（可用RUN useradd -r -u 1001 appuser创建） - 指定 UID/GID 更稳妥：
USER 1001:1001不依赖用户名解析，避免镜像跨平台时因 /etc/passwd 差异出错 - 注意：某些基础镜像（如
alpine:latest）默认不含useradd，需改用adduser或直接用 UID
为什么在 Docker Desktop 里加 docker 用户组没用
因为 Docker Desktop 在 Windows/macOS 上不使用 Unix socket（/var/run/docker.sock）通信，而是走本地 HTTP API 或 WSL2 命名管道；所以 sudo usermod -aG docker $USER 这套机制只对 Linux 宿主机有效，对 Desktop 用户完全无关：
- Windows 用户无需、也不能加入
docker组——Desktop 启动时自动申请管理员权限并托管守护进程 - macOS 用户同理，Docker Desktop 安装后会注册为系统服务，CLI 命令直连本地 daemon，不依赖用户组
- 真正要控制的是容器内进程身份（
--user或USER），不是宿主机 CLI 权限
最容易被忽略的一点：在 Docker Desktop + WSL2 环境下，--user 和挂载卷权限的配合必须在 WSL2 文件系统内验证，不能只看 Windows 资源管理器显示的“所有者”——那里根本不显示 UID/GID。
