Mac 上用 Docker Desktop，本地开发前先看资源限制

很多人刚在 Mac 上装好 Docker Desktop，第一反应都是先拉镜像、起容器、跑服务。等到容器越来越多，才开始发现编译慢、数据库启动慢、桌面风扇狂转、系统内存被吃掉一大块。这个时候再怀疑镜像源、怀疑命令写法，往往已经偏题了。对 Mac 环境来说，资源限制配置本身就是本地开发体验的一部分。

Docker Desktop 不是“凭空多出一台 Linux”

在 Mac 上跑 Docker 时，背后其实还是通过虚拟化方式提供 Linux 环境。也就是说，CPU、内存、磁盘这些资源都需要你明确分配。你不给，它就只能在默认值里周旋；你给得太激进，又会反过来把宿主机拖慢。

所以我现在每次新机器装完 Docker Desktop，都会先看资源设置，而不是先追求把所有服务一次性拉起来。因为很多所谓“容器很慢”的问题，本质上只是资源预算没有提前想清楚。

本地开发要按“同时运行的服务数”来估算

如果只是偶尔起一个 Nginx 或 Redis，默认设置问题不大。但只要你本地要同时跑 API、数据库、消息队列、管理后台，资源配置就不能再靠感觉。尤其数据库和搜索类服务，对内存敏感得多。

我比较实用的做法是先列出开发时真正会一起运行的服务，而不是把所有可能用到的镜像都算进去。这样配出来的资源更接近真实场景，也不会让机器在闲时白白背负过高占用。

慢的时候先看哪几项

如果容器启动和执行命令突然变慢，我一般优先看下面几件事：

• Docker Desktop 分配的内存是否过低
• CPU 核心数是否限制得太保守
• 磁盘镜像是否已经膨胀，导致 IO 变差
• 同时运行的容器里，是否有数据库、ES 这类重服务

这些检查做完，再去怀疑镜像源或者网络，排查顺序会稳很多。因为镜像拉取慢是一类问题，容器运行慢是另一类问题，别混在一起。

给本地环境留余量，比卡着极限更舒服

很多人喜欢把资源刚好配到“能跑起来”就算完，其实这对开发体验并不友好。因为一旦你同时开浏览器、IDE、数据库客户端，再加上容器里的编译或索引任务，系统很容易立刻进入紧绷状态。

我更倾向于给宿主机预留明显余量。Docker 能稳定跑固然重要，但本地开发不是只有 Docker 一个程序。能让整台机器保持流畅，效率反而更高。

先把资源面板看懂，后面很多问题都会简单

Docker Desktop 在 Mac 上的很多使用问题，并不是命令本身的坑，而是环境预算没先打好。把资源限制先看清楚，你会更容易判断后面遇到的是网络问题、镜像问题，还是单纯机器已经扛不住了。

本地容器工作流要稳定，第一步往往不是多学几个命令，而是先把运行环境的天花板看明白。