Docker Desktop界面无法全局配置容器启动参数，真正控制容器行为需在docker run命令、docker-compose.yml或Dockerfile中显式声明；Settings→Resources中设置的是底层VM资源上限，非单个容器参数。
不能在 Docker Desktop 界面里“填写启动参数”来影响容器的 docker run 命令行为——Docker Desktop 本身没有提供全局配置项让你直接往每个容器的 run 命令里塞自定义参数。你真正能控制容器启动参数的地方，是写命令时自己加，或用 docker-compose.yml、Dockerfile 显式声明。
docker run 命令里传参才是真启动参数
所谓“向容器传入参数”，本质就是你在终端执行 docker run 时加的那些 flag 和参数。Docker Desktop 只是帮你启了 daemon，它不拦截也不改写你的 run 命令。
-
-e KEY=VALUE：传环境变量，比如-e NODE_ENV=production -
-v /host/path:/container/path：挂载宿主机目录，注意 Windows 路径要写成C:/path或/c/path -
--network host或--network mybridge：指定网络模式，host在 macOS/Windows 不生效（只对 Linux 宿主机有效） -
--shm-size=2g：增大共享内存，对 OpenCV、PyTorch 多进程 dataloader 很关键 -
--ulimit nofile=65536:65536：避免容器内程序因文件描述符不足崩溃
Docker Desktop 设置页里的“Resources”不是容器启动参数
Settings → Resources 里调的 Memory、CPU、Swap，是限制 Docker Desktop 底层 Linux VM（WSL2 或 Hyper-V 虚拟机）的资源上限，不是传给单个容器的 --memory 或 --cpus。两者作用层级不同：
- VM 级限制：影响所有容器总和能用多少资源，改完要重启 Docker Desktop 才生效
- 容器级限制：必须显式写在
docker run或docker-compose.yml里，比如--memory=1g --cpus=1.5 - 若 VM 只配了 2GB 内存，但你给某个容器设了
--memory=4g，容器仍会因 OOM 被 kill，且不会报错提示冲突
docker-compose.yml 是最稳妥的参数管理方式
比起反复敲长命令，把参数固化在 docker-compose.yml 里更可靠，尤其涉及多容器协作时。注意几个易错点：
-
deploy.resources.limits只在docker stack deploy时生效，docker-compose up默认忽略它（除非加--compatibility） - 想让
docker-compose up尊重内存/CPU 限制，得用mem_limit和cpus字段（不是deploy下的）：
version: '3.8'
services:
app:
image: nginx:alpine
mem_limit: 512m
cpus: '0.5'
environment:
- TZ=Asia/Shanghai
volumes:
- ./conf:/etc/nginx/conf.d
- Windows/macOS 上用
volumes时，宿主机路径必须是绝对路径，且需提前在 Docker Desktop → Settings → Resources → File Sharing 中勾选对应盘符或目录（否则挂载失败且无明确错误）
别信“Docker Desktop 启动参数配置”这类误导标题
网上很多教程说“修改 Docker Engine 配置 JSON 加 --insecure-registry 就能传参”，那是给 daemon 自己用的参数（如私有 registry、镜像加速器），跟容器启动完全无关。真正的容器参数永远只出现在三处：
- 你亲手敲的
docker run ...命令行 - 你写的
docker-compose.yml的services.xxx下字段 - 你写的
Dockerfile中的ENTRYPOINT和CMD（它们决定容器启动时执行什么，以及是否接受外部参数）
混淆这三层，就会卡在“为什么我改了 Settings 却没生效”。参数不在界面上填，而在命令、YAML 或 Dockerfile 里写——这是最容易被跳过的事实。
