企业官网建设流程全解析

第一次在一台M1芯片的MacBook Air上装Docker Desktop，装完满怀期待地打开，盼着看到那个蓝色鲸鱼图标稳定运行。结果迎面而来的是一行红字：Docker Desktop failed to start because virtualisation support wasn‘t detected。那一瞬间是真有点懵——这台机器刚买没多久，系统是新的，配置也不低，怎么看都不是“不支持虚拟化”的样子。

后来才发现，Mac OS上安装Docker容器这件事，真正的难点从来不在“下一步下一步”，而在于你的机器芯片、系统版本、虚拟机框架和镜像网络之间，存在一堆文档里找不到的隐性规则。这篇文章我会把从选型、安装、跑通第一个容器，到MySQL、Redis这类实际负载部署，再到故障排查的完整链路一次讲透。无论你是刚接触容器的新手，还是在Mac上被Docker折腾过的开发者，应该都能从中找到对应自己那个场景的解法。

1. 先别急着装：Mac上跑容器的几条路线，选错后面都难受

很多人一上来就直接搜“Docker Desktop下载”，装完才发现资源占用高、启动慢、公司规模大了License还有限制。其实Mac OS上运行Docker容器并不是只有官方客户端这一条路，先搞清楚各条路线的差异，比急着安装更重要。

1.1 Docker Desktop是默认答案，但不是唯一答案

Docker Desktop是Docker官方出品的桌面客户端，针对macOS做了深度整合。它最大的优势是开箱即用：下载dmg、拖进Applications、打开，图形界面里就能管理镜像、容器、卷和构建缓存，还能一键开启Kubernetes。团队协作时，别人问你用的什么环境，你回答Docker Desktop，沟通成本最低。

但它的代价也不小。首先是资源占用，Docker Desktop在Mac上默认会创建一个Linux虚拟机，这个虚拟机会吃掉不少CPU和内存，哪怕你一个容器都没跑，后台进程依然在。其次是许可问题，2021年8月之后，Docker Desktop对大型企业（员工超250人或年收入超1000万美元）开始收费。如果你在公司电脑上装，合规部门可能真的会找上门。

1.2 Colima、OrbStack、Podman到底适合谁

• Colima：命令行工具，底层复用Lima虚拟化方案，免费开源。它不提供图形界面，一切通过colima start这类命令控制。适合习惯于终端操作、不希望被GUI绑架的开发者。
• OrbStack：近年口碑很好的轻量级替代品，官方定位是“Mac上最快的Docker容器运行环境”。它同样提供GUI，但比Docker Desktop轻得多，启动速度也快，对Linux虚拟机的管理更高效。很多人从Docker Desktop迁移过来之后最直观的感受就是风扇不转了。
• Podman：无守护进程的容器引擎，命令与Docker高度兼容（docker可以直接别名到podman）。它的安全模型更先进，但在Mac上同样需要一个虚拟机来跑Linux容器，配置起来比前面几个稍麻烦。

我的建议是：如果只是个人学习、小型项目开发，直接用Docker Desktop最省心；如果你发现Mac风扇常年高速运转、磁盘被Docker占掉几十G，试试OrbStack；如果你本身是命令行重度用户且不排斥折腾，Colima是性价比很高的选择。下面所有步骤我以Docker Desktop为主线讲，因为它的安装和后续命令在其它方案上也通用，版本差异不大。

2. 被最多人忽略的第一步：你的Mac芯片和系统版本决定一切

Mac OS上安装Docker，第一步不是下载安装包，而是先确认两个硬指标：芯片类型和macOS版本。这两者决定了你能不能装、装哪个版本、会遇到什么报错。

2.1 Apple Silicon与Intel在虚拟化上的本质差异

Docker在Mac上运行Linux容器，本质上需要在macOS里跑一个轻量级Linux虚拟机。早期Docker Toolbox时代用的是VirtualBox，性能和体验都一言难尽。后来Docker Desktop转向了macOS自带的虚拟化框架。

关键分水岭在2020年：Apple发布M1芯片后，Intel Mac和Apple Silicon Mac走的是完全不同的两套虚拟化实现。Intel Mac上，Docker Desktop依赖英特尔的VT-x硬件虚拟化技术；而Apple Silicon上，它使用的是Virtualization.framework，这是苹果自己的原生虚拟化方案。

这意味着什么？你在网上搜到的大部分老教程，尤其是基于Intel Mac写的排错经验，在M系列芯片上根本不适用。反过来也一样。所以先确认机器情况：

• 点击左上角苹果图标 → 关于本机，查看“芯片”一栏是Apple M1/M2/M3还是Intel。
• 点击“更多信息”→ 系统报告，查看macOS版本号。

兼容关系大致如下：

• Apple Silicon（M1/M2/M3）：要求macOS 11 Big Sur或更高版本，Docker Desktop 4.3开始原生支持。
• Intel：要求macOS 10.15 Catalina或更高，且必须开启VT-x。
• 如果你的系统版本过低，Docker Desktop新版会直接拒绝启动，或者安装后一直卡在引擎启动界面。

2.2 “virtualisation support wasn’t detected”这条报错的真实来源

现在回看开头那个报错，它几乎成了Mac装Docker的头号劝退信息。根据我自己和各社区开发者反馈，这条报错常见于以下几类情况，我按出现频率排个序：

1. 旧版Docker Desktop与新macOS版本不兼容。Docker引擎启动时调用虚拟化框架失败，但报错信息没有说清楚是版本问题。解决办法是升级到最新版Docker Desktop。
2. 安装后没有完全退出旧进程。如果你之前装过Docker Toolbox或老版本Docker，旧进程残留在后台，新版本启动时会撞车。解决办法是彻底退出所有Docker相关进程再启动。
3. Intel Mac上VT-x被关闭。这种情况多出现在老款Mac或系统安全设置被改动过的机器上，需要在重启时进入启动管理器确认固件设置。
4. 在虚拟机里跑Docker Desktop。如果你本身就在Parallels或VMware里装了macOS，再在里面装Docker Desktop，嵌套虚拟化基本行不通，会直接报这个错。

排查顺序建议是：先检查系统版本和Docker Desktop版本是否为最新，再清理残留进程重启，最后才考虑硬件层面的虚拟化开关。大多数人走到第二步就能解决了。

3. 从下载到跑通hello-world：完整安装流程里的每个细节点

确认完芯片和系统版本，下面进入正题。这一步本身不难，但有几个细节点容易卡住新手，我一个个说。

3.1 下载安装的两种方式与首次启动

第一种方式是直接在官网下载dmg安装包，然后像安装普通Mac软件一样操作。要注意的是，如果你的网络环境访问官网比较慢，下载过程可能非常熬人。更推荐的做法是用Homebrew安装，命令只有一行：

brew install --cask docker

Homebrew会自动下载并安装到/Applications目录，后续升级用brew upgrade docker就能搞定，比每次手动去官网下载方便得多。

安装完成后，第一次打开Docker.app时，macOS的Gatekeeper可能会拦截，提示“无法打开，因为无法验证开发者”。这是因为Docker Desktop在默认情况下没有通过App Store分发，Mac会对这种应用做安全校验。遇到这个提示，到“系统设置 → 隐私与安全性”里，找到被拦截的应用，点击“仍要打开”即可。

3.2 资源配置与Docker环境验证

第一次启动Docker Desktop后，它会要求你接受服务条款，然后进入Dashboard界面。此时右下角状态栏的鲸鱼图标可能还在转圈，说明引擎还在初始化，等它稳定不变色就好了。

进入Dashboard的Settings，找到Resources，我强烈建议一上来就修改两个默认值：

• CPU：建议至少保持默认，如果你平时跑多个容器（比如MySQL、Redis、Nginx同时开），给它一半以上的核心数。
• 内存：默认是2GB，这在跑容器时会非常紧张。建议开发机至少给4GB，如果有16GB以上内存的机器，可以分8GB给Docker。

改完设置后，点击Apply & Restart，引擎会重启一次。然后打开终端验证环境是否正常：

docker version

如果能看到Client和Server两段信息，Server段包含Operating System: Docker Desktop，就说明引擎已经在正常运行了。接着跑第一个容器验证：

docker run hello-world

这条命令会先从Docker Hub拉取一个极小的测试镜像，然后在容器里执行一段欢迎信息。如果能看到完整的输出，恭喜你，Docker环境已经正式跑通了。

这里插一句经验：很多人在这一步就会遇到镜像拉取超时的问题，也就是命令卡在Pulling from library/hello-world半天没反应。这个问题很常见，我在下一节专门讲。

4. 镜像拉取慢怎么办：macOS平台上的加速与镜像源配置

如果说安装Docker是入门，那拉取镜像是很多Mac用户在实际使用中遇到的第一个真正的坎。默认情况下，Docker会从Docker Hub拉取镜像，这个公共仓库在部分地区访问速度极不稳定，一个几百MB的镜像拉到天荒地老也不是稀罕事。

4.1 为什么会慢，慢在哪个环节

Docker拉取镜像的过程分几层：客户端发起请求、Docker Hub返回镜像清单、客户端逐层下载、校验并解压。慢的环节主要在网络层。常见表现有两种：一种是直接超时报错，提示net/http: TLS handshake timeout；另一种是长时间卡在某个层，进度条纹丝不动。

在Mac上，还有一个容易被忽略的问题：容器内部的DNS解析。即便你的Mac本身网络正常，Linux虚拟机内部可能无法正常解析Docker Hub的域名，导致看似卡住，其实是解析失败。

4.2 Registry Mirror配置实操

解决拉取慢的标准做法是配置镜像加速器。Docker支持多个Registry Mirror，你可以在Docker Desktop的配置里一次性添加。打开路径：Docker Desktop → Settings → Docker Engine，然后编辑JSON配置：

{ "registry-mirrors": [ "https://docker.m.daocloud.io", "https://dockerpull.org", "https://hub.rat.dev" ] }

注意，这里替换的是registry-mirrors项。保存后，Docker引擎会自动重启，使配置生效。验证是否配置成功：

docker info

在输出信息里找到Registry Mirrors一节，如果显示了刚才填的地址，说明加速已经生效。之后再拉取镜像，速度会有肉眼可见的提升。

几个提醒：

• 不要同时堆太多加速地址，两三个足够，多了反而会增加解析负担。
• 这些公共加速器存在一定时效性，如果某一天某个地址失效，换一个更新过的即可，配置方式完全一样。
• 千万不要使用来路不明的“一键加速脚本”，那些脚本往往会在你不知情的情况下读取Docker配置甚至把镜像仓库指向未知服务器，安全风险极高。

4.3 企业场景下的镜像仓库方案

如果你是在公司网络环境里部署，公共加速器可能根本用不了，或者出于安全策略不允许直连外网。这种场景下，常规做法是部署私有镜像仓库，比如Harbor或云厂商提供的容器镜像服务。团队内部把基础镜像推送到私有仓库，然后所有成员把registry-mirrors指向内网地址。这不仅解决了拉取慢的问题，还为镜像安全管理打了底子。关于镜像安全，后面专门开一节说。

5. 容器不是虚拟机：端口、数据卷与生命周期是另一个世界的规则

很多人第一次用Docker，会把容器当成一个轻量级虚拟机来用，由此产生一堆误解：进容器里改了文件，重启容器发现改动没了；明明容器在运行，浏览器却访问不到服务；容器停了再启动，数据全丢了。这一节把容器和虚拟机最关键的三个差异讲透。

5.1 端口映射到底发生了什么

虚拟机有独立的IP地址，你访问虚拟机里的服务时，直接访问那个IP就行。但容器不一样，容器共享Mac主机的网络栈，对外没有独立的IP（在默认bridge模式下）。所以你要访问容器里的服务，必须做“端口映射”：把主机的某个端口映射到容器的某个端口。

命令格式是-p 主机端口:容器端口。举个例子：

docker run -d --name nginx-demo -p 8080:80 nginx

这条命令的含义是：把容器内部的80端口，映射到Mac主机的8080端口。之后你在浏览器访问http://localhost:8080，流量会先到Mac主机的8080端口，被转发到容器内的80端口，由Nginx接收处理。

理解这个映射关系可以帮你快速定位很多问题。比如容器明明在运行但访问不了，先检查是不是主机端口被别的进程占了（后面排查章节细讲），再看看是不是端口映射写反了，把80:8080写成了8080:80，那情况就反了。

5.2 数据卷：容器删了数据为什么还在

容器的可写层是临时的，容器被删除后，这一层的数据也会随之消失。如果你直接在容器里创建文件、写数据库，不挂载数据卷，容器一删，数据就没了——这不是故障，这是容器设计的基本规则。

要保留数据，必须使用数据卷（Volume）或绑定挂载（Bind Mount）。最直观的是绑定挂载，把主机的某个目录直接映射进容器：

docker run -d --name mysql8 \ -e MYSQL_ROOT_PASSWORD=strongpass \ -v ~/mysql-data:/var/lib/mysql \ mysql:8.0

这条命令把宿主机上的~/mysql-data目录映射到容器内的/var/lib/mysql目录。MySQL往/var/lib/mysql里写数据，实际上就是往Mac的~/mysql-data里写。哪怕你把容器删了、镜像删了，数据都还在Mac上，换个新容器重新挂载同一个目录，数据无缝恢复。

这个习惯一定要从第一次跑容器就养成：凡是有状态的服务（数据库、缓存、文件存储），必须挂数据卷。

5.3 容器生命周期与常用命令

容器生命周期管理也是绕不开的。我把日常最常用的命令整理成一张速查表：

有个细节值得强调：docker run和docker start是两个不同操作。docker run是创建并启动一个新容器，每次执行都会产生一个新的容器实例；docker start是启动已存在的容器。我见过不少人想重新启动一个容器，结果又执行了一遍docker run，最后发现同名容器冲突，报错Conflict. The container name "/xxx" is already in use。这时候用docker start就对了，或者把旧容器删掉再docker run。

6. 拿实际工作负载开刀：MySQL 8.0与Redis的容器化部署

环境装好、概念理清之后，最好通过一两个真实项目把整套操作串起来。这里我用MySQL 8.0和Redis主从两个场景，完整演示从单容器到多容器的部署过程。

6.1 跑一个带数据卷的MySQL

MySQL是容器化最典型的应用之一。很多人在自己的Mac上装原生MySQL，碰到版本冲突、卸载残留、权限问题，折腾半天。用Docker之后，这些问题基本消失，只需要一条docker run。

完整命令如下：

docker run -d \ --name mysql8 \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORD=root123 \ -e TZ=Asia/Shanghai \ -v ~/mysql-data:/var/lib/mysql \ mysql:8.0 \ --character-set-server=utf8mb4 \ --collation-server=utf8mb4_unicode_ci

逐个解释参数：

• -d：后台运行。
• --name mysql8：给容器命名，方便后续管理。
• -p 3306:3306：把主机的3306端口映射到容器的3306端口。注意，如果你的Mac本地已经装了MySQL并用着3306端口，这里会冲突，改成3307:3306。
• -e MYSQL_ROOT_PASSWORD：设置MySQL root密码。
• -e TZ=Asia/Shanghai：设置容器时区，不加的话默认UTC时间，日志时间和本地时间差8小时，排错时会困惑。
• -v ~/mysql-data:/var/lib/mysql：数据卷挂载，重点中的重点。
• mysql:8.0：镜像名加标签，8.0固定大版本，不建议用latest。
• 后面两行--character-set-server和--collation-server是传给MySQL启动的参数，设置字符集和排序规则，避免中文乱码。

跑起来之后验证一下：

docker exec -it mysql8 mysql -uroot -p

输入密码进入MySQL命令行，执行SHOW VARIABLES LIKE ‘character%’;确认字符集是utf8mb4，就说明一切正常。

6.2 docker-compose管理多容器：Redis主从示例

单容器用docker run没问题，一旦涉及多个容器，比如一个项目同时要MySQL、Redis、Nginx，再一个个敲docker run就很容易乱。这时候用docker-compose来编排。

以Redis一主一从为例，新建一个目录，在里面创建docker-compose.yml：

services: redis-master: image: redis:7 container_name: redis-master ports: - "6379:6379" command: ["redis-server", "--appendonly", "yes"] redis-slave: image: redis:7 container_name: redis-slave depends_on: - redis-master ports: - "6380:6379" command: ["redis-server", "--slaveof", "redis-master", "6379"]

然后在目录下执行：

docker compose up -d

-d表示后台运行。执行docker compose ps可以看到两个容器的状态。进入从节点验证主从是否生效：

docker exec -it redis-slave redis-cli INFO replication

看到role:slave且master_link_status:up，说明主从已经建立。这个示例虽然简单，但涵盖了compose文件的核心写法：定义服务、配置端口映射、指定启动命令、用depends_on控制启动顺序。实际项目中，可以把MySQL、Redis、后端服务、前端服务都写进同一个compose文件，一条命令全部拉起。

需要注意的是：新版Docker Compose命令是docker compose（中间有空格），旧版的docker-compose（横杠）是独立二进制，如果你用的Docker Desktop版本较老，可能需要先安装docker-compose。

6.3 给容器加上资源上限

回到热搜词里那条“docker-compose up限制容器配置”，很多人在生产环境或本地资源紧张时，需要限制单个容器能占用的CPU和内存。在compose文件里可以这样配置：

services: redis-master: image: redis:7 deploy: resources: limits: cpus: '0.5' memory: 512M reservations: cpus: '0.25' memory: 256M

limits是硬上限，超过会被杀掉或触发OOM。reservations是预留值，正常情况下容器至少能拿到这么多资源。本地开发时给Redis这类轻量中间件限制512M内存完全够用，能有效防止单个容器吃满整台机器。

7. Mac上最容易踩的六个坑：从失败日志到最终修复的完整排查

这一节是全文最有“泥土味”的部分。我整理了在Mac上使用Docker过程中最高频的六个问题，每个都给出从现象到根因再到修复的完整排查链路，不讲空话。

7.1 Docker Desktop无法启动的故障树排查

现象：点击Docker Desktop图标，鲸鱼图标一直转圈，或者直接报错“Docker Desktop failed to start because virtualisation support wasn‘t detected”。

这是开篇提到的那个头号问题。完整的排查顺序是这样的：

第一步，确认版本兼容性。打开“系统设置 → 通用 → 软件更新”，确认macOS是最新版本。然后到Docker Desktop官方发布页看当前版本的系统要求。如果是旧版本，直接升级Docker Desktop，这一步能解决大半问题。

第二步，清理残留进程。打开终端执行：

pkill -f Docker

然后重启Docker Desktop，很多“卡在启动界面”的问题就这么解决了。如果你之前装过Colima或OrbStack，它们可能在后台占用着同一套虚拟化资源，先停掉：

colima stop

第三步，查看引擎日志。Docker Desktop的日志文件在~/Library/Containers/com.docker.docker/Data/log/host/目录下。打开vm开头的日志文件，搜索error或failed关键词。很多新手在这一步会被大段日志吓退，其实只要定位到报错行。

第四步，如果前三步都没解决，卸载重装。卸载时不仅要删除/Applications/Docker.app，还要清理配置目录：

rm -rf ~/Library/Containers/com.docker.docker rm -rf ~/Library/Group\ Containers/group.com.docker

注意，这会把本地的镜像和容器配置全部清空，操作前确认没有重要数据未备份。

7.2 端口被占用的检查套路

现象：容器正常运行，但浏览器访问localhost:8080一直打不开，或者打开的是别的页面。

先说原理：Mac上多个进程不能同时绑定同一个端口。如果你用-p 8080:80启动Nginx容器，但Mac的8080端口已经被其他服务（比如另一个Java进程、Homebrew的Nginx）占用，Docker会报错，或者容器起了但请求根本到不了Docker。

排查命令：

lsof -i :8080

看到输出里有进程占用，再确认那个进程是什么。如果是自己起的服务，有两种选择：停掉占用进程，或者干脆改容器映射端口：

docker run -d --name nginx-demo -p 8081:80 nginx

访问http://localhost:8081即可。

一个细节：Docker内部网络也可能存在端口占用，但这种情况很少见，绝大多数端口访问不了都是主机层面的问题。

7.3 容器秒退的第一次debug应该看什么

现象：docker run之后，容器立刻退出，docker ps看不到它，要用docker ps -a才能看到状态是Exited。

刚接触Docker的人遇到这种情况经常会慌，以为环境坏了。其实容器立刻退出，大部分原因很简单：容器里的主进程结束了，容器就退出了。就像你开了一个终端，执行完一条命令，终端窗口自然就关了。

排查流程分两步：

第一步，看退出状态码。docker ps -a输出里有一列STATUS，比如Exited (0)表示正常退出，Exited (1)表示程序执行时报错退出，Exited (137)表示被系统杀掉（通常是内存超限）。不同退出码指向不同方向。

第二步，看日志。执行：

docker logs 容器名

如果是类似Error: listen EADDRINUSE，说明容器内端口也被占用（这种情况极少）。如果是executable file not found，大概率是启动命令写错了路径。

新手另一个常见错误是没有加-d参数，容器在前台运行，关闭终端时容器跟着退出。这种不算故障，把命令改成docker run -d就行。

7.4 磁盘空间无端暴涨的处理顺序

现象：Mac磁盘空间越来越小，奇偶鲸鱼图标已经跑到警告状态。

Docker在Mac上会创建一个虚拟磁盘镜像文件（Docker.raw），它的大小是动态增长的：你拉取的镜像越大、容器产生的数据越多，这个文件就越大。问题在于，删除镜像和容器后，这个虚拟磁盘文件不会自动缩小。

处理顺序如下：

第一步，清理悬空镜像和未使用的缓存：

docker system prune -a --volumes

注意这个命令会删除所有未被运行中容器使用的镜像、停止的容器和未使用的卷。执行前确认没有需要保留的东西。

第二步，如果清理完磁盘空间依然没释放多少，在Docker Desktop的Settings → Resources → Disk里，点击清理按钮，或者直接调整虚拟磁盘大小。还有一招是重置磁盘镜像，路径在Troubleshoot → Clean / Purge data。

第三步，日常预防。定期用docker system df查看磁盘占用构成，关注Build Cache和Images占据的空间。长时间不用的镜像及时删除，docker rmi 镜像ID就行。

7.5 Docker占用CPU飙高的排查思路

现象：Mac风扇狂转，打开活动监视器看到Docker相关进程CPU占用极高。

先分清是哪一层在吃CPU：是Docker Desktop的前端界面进程，还是vm虚拟化进程，还是某个容器内的进程。用docker stats可以实时查看每个容器的CPU占用。

常见原因和对应解法：

• 某个容器在跑死循环或高负载任务：直接在docker stats里找到异常容器，重启或删除。
• 日志采集工具（如Filebeat、Logstash）在容器内不断扫描大量文件：限制容器的CPU上限，docker update --cpus 1 容器名。
• Docker Desktop自身的后台进程异常：重启Docker Desktop通常能解决，依然不行就清理配置之后重装。

还有一种容易被忽略的情况：你同时装了Docker Desktop和OrbStack/Colima，它们各自跑着一个Linux虚拟机，叠加起来资源占用自然高。这种问题没有太好的解法，只能做减法，只留一个。

8. 镜像安全与资源底线：用容器不等于随手拉镜像

容器用顺手之后，很多人会忽略一件事：Docker用得越频繁，镜像来源、配置信息和资源占用的风险就越大。这一节不聊复杂的安全框架，只讲两个务实底线：怎么选镜像，怎么管资源。

8.1 镜像安全，从固定版本和来源校验开始

镜像安全是目前容器领域被讨论最多的话题之一。一个不安全的基础镜像，可能把漏洞、后门、恶意依赖带进你的开发和部署环境。

三件事值得从今天开始执行：

• 不用latest标签。镜像版本更新不可控，今天能跑的latest，明天可能就被覆盖成兼容性有问题的版本。固定到大版本如mysql:8.0，最好固定到具体版本如mysql:8.0.36。
• 优先选择官方镜像。在Docker Hub上，标注为Docker Official Image的镜像，经过官方维护，质量相对可靠。从个人仓库拉镜像时，留意镜像的pull次数、维护活跃度、star数量。
• 不再镜像里留密钥。这是一个非常常见且隐蔽的问题：为了方便构建，有人把数据库密码、API Key直接写进Dockerfile或环境变量文件，然后把镜像推到仓库里。镜像一旦被外部获取，密钥就彻底暴露了。密钥应该通过运行时环境变量或Secret管理工具注入。

如果你想更进一步，可以在推送或使用镜像前用docker scout之类的工具扫描漏洞：

docker scout cves mysql:8.0

它会输出对应镜像存在的已知CVE列表和严重等级，帮你判断这个镜像能否用于生产环境。

8.2 容器不是无限资源：CPU内存限制的配置

在本机开发时，如果不限制容器的资源占用，一个失控的容器可能把Mac的内存吃完，导致系统整体卡顿甚至自动重启。之前提到过--memory和--cpus参数，单独用docker run时这样限制：

docker run -d --name nginx-demo --memory 512m --cpus 0.5 nginx

对于已经运行的容器，可以用docker update动态调整：

docker update --memory 1g --cpus 1 mysql8

在团队协作的场景，compose文件里的deploy.resources.limits是统一管理资源配额的正确位置。把资源限制写进配置文件，而不是依赖每个人手动传参，管理起来会省心很多。

最后再说一个和资源相关但经常被忽视的细节：Docker Desktop本身有一个“启动时自动开启”的选项，如果不开，只有在你主动打开Docker Desktop时容器环境才启动，这对那些不常跑容器的轻量用户来说，能省下大量内存和电量。用完容器顺手关掉Docker Desktop，Mac会感谢你。

从最早在Intel Mac上装Docker Toolbox开始，到后来在M1芯片上用Docker Desktop，再到现在折腾Colima、OrbStack这些新方案，这些年我在Mac上跑容器的体验经历了从“装得上就谢天谢地”到“可以按需选择最优方案”的变化。如果让我只留一条经验给刚入门的读者，那就是：先花十分钟搞清楚自己的芯片、系统和需求，再决定装什么、怎么装，比盲目跟着教程敲命令重要得多。Docker这套东西，本质上并不复杂，大多数所谓的问题，其实是对底层规则的误解。把端口映射、数据卷、资源限制这三个概念想透了，你在Mac上运行容器这件事，就已经超过了一半的人。