M1 Mac mini 重装 macOS 后的开发环境配置：Homebrew、fnm、pnpm 与常用工具清单

重装 macOS 之后，先想清楚这台机器要拿来干什么

M1 Mac mini 用上两三年再重装系统，多数时候不是机器坏了，而是环境变脏了。256GB 的版本感受最直接：Xcode 缓存、Simulator Runtime、pnpm store、试用过一两次就没再打开的 Docker 镜像、好几个版本并存的 Node，加起来能吃掉几十 GB。等磁盘只剩个位数空间，编译变慢、IDE 索引报错、系统更新装不进去，问题就不是一个而是一串。

来源作者这次动手的触发点正是磁盘长期吃紧，已经影响到正常开发。如果你也是类似处境，与其马上开装软件，不如先定三条规则，后面的取舍会清楚很多。

第一条，只装每天真会用的工具。装的时候很爽，维护的时候全是债，尤其是那些只在某篇教程里出现过一次、之后再没用过的 CLI。第二条，同类工具只留一个：一个版本管理器、一个包管理器、一个数据库客户端；同时装三四个，最后连自己都记不清哪个在生效。第三条，能项目级安装就别全局安装——全局依赖一旦被升级，老项目经常当场打不开。

下面按「前置条件 → 系统底座 → Shell 与 Git → Node 生态 → Python 与数据库 → IDE 与调试工具 → Cloudflare 工具 → 磁盘治理 → 回滚与自检」的顺序走一遍。你可以从头照做，也可以只挑自己缺的那几段。涉及安装脚本路径、命令写法和磁盘阈值的地方，以各工具官方文档和你的实际使用情况为准。

前置条件：哪些机器适合按这篇走，动手前要准备什么

这篇教程不是给所有 Mac 用户写的，先把前提说清楚，省得你做到一半发现走错了路。

硬件与系统前提。 本文针对的是 Apple Silicon 机型，M1 的 Mac mini 是典型对象，M2、M3、M4 的 Apple Silicon Mac 同样适用，因为架构都是 ARM64。Intel 芯片的 Mac 也能配开发环境，但路径前缀、部分工具的兼容表现不一样，别直接照抄本文的 /opt/homebrew 相关命令。系统版本方面，能在 App Store 里正常安装 Xcode、并且终端默认使用 Zsh 的 macOS 版本都可以，太老的系统请先升级再动手。

动手前的准备。 重装系统会清空本机数据，这一步不能省。把还没推上远端的代码提交并推送；把 ~/.ssh、~/.zshrc、~/.zprofile 以及各类 dotfiles 备份到云盘或私有仓库；顺手记一下当前机器的磁盘占用大头在哪，重装完可以直接对照。三件事做完，重装的风险基本可控，真出问题也能快速回到可用状态。

迁移助理要不要用，提前想清楚。 迁移助理会把旧环境里的垃圾一起搬过来。如果你重装的动机就是清理环境，更推荐只迁移文档、照片和密钥，软件全部重装。

谁不适合照搬这套方案。 需要长期 7×24 在线、要固定公网入口的服务，不该塞进这台 Mac mini，这类需求后文会单独讲；日常重度使用 Docker 做多容器编排的人，256GB 的配置本身就偏紧，本地环境不是主要矛盾；只在 Mac 上做文档、写写脚本、几乎不碰 Node 和编译的人，也不必装一整套工具链。

第一步装什么：Xcode Command Line Tools 和 Homebrew

顺序上，先装 Xcode Command Line Tools，再装 Homebrew。很多命令行工具依赖 git、clang 这些基础组件，缺了它们 Homebrew 会在编译环节报错。Command Line Tools 不需要打开 Xcode，执行 xcode-select --install 后跟着图形提示走完即可。

Homebrew 在 Apple Silicon 上用官方安装脚本安装，装完之后要把 eval "$(/opt/homebrew/bin/brew shellenv)" 写进 ~/.zprofile，这样新开的终端才能识别 brew 命令。这一步没做的话，旧标签页看着一切正常，新开一个窗口就提示 command not found，很多人会误以为安装失败。

验证很简单：新开一个终端窗口，执行 brew --version 和 which brew。前者有版本号、后者指向 /opt/homebrew/bin/brew，说明环境和 PATH 都对。如果路径指向 /usr/local/bin/brew，说明你装成了 Intel 版本，建议卸载重来，否则后续的 Rosetta 兼容问题会一直缠着你。

图：安装顺序不必严格线性，但底座要先立起来，后面每一步都依赖它。（配图占位，正式发布前替换为 16:9 内容图）

Shell 与 Git：Zsh、Oh My Zsh、SSH 一次配完

macOS 默认的登录 Shell 就是 Zsh，不需要额外安装 Zsh 本身，网上让你 brew install zsh 的步骤可以直接跳过。真正要做的是配置。Oh My Zsh 负责补全、主题和插件管理，装完之后把插件列表写进 ~/.zshrc。

插件不用贪多。对开发机来说，git、zsh-autosuggestions、zsh-syntax-highlighting 这三个已经覆盖了绝大多数日常需求，也基本是社区里提得最多的组合。插件越多启动越慢，装十几个最后常用的还是那几个，反而拖慢每次开终端的手感。

Git 用 Homebrew 装即可，装完设好 user.name 和 user.email。SSH 这块建议重装后重新生成密钥，把公钥加到 GitHub，再用 ssh -T [email protected] 测试。返回欢迎信息就说明通了；如果提示权限错误，多半是公钥贴错或者代理配置没清干净。

如果你之前用过多个 Git 账号，重装后最好一次性理清：工作账号用一份密钥加 ~/.ssh/config 里的 Host 别名区分，别指望靠全局配置来回切，那是最容易出事故的做法。

Node.js 版本管理：用 fnm，而不是全局 Node

直接在 Homebrew 里装一个全局 Node，短期看最省事，长期看最容易出问题。不同项目对 Node 大版本的要求不一样，全局只有一个版本时，你会在多个项目之间反复升级和降级，最后自己也记不清当前是哪个版本。

fnm 是一个轻量的 Node 版本管理器，用 Rust 写的，启动比 nvm 快一些。装好之后在 ~/.zshrc 加上初始化语句，进入带 .node-version 或 .nvmrc 的项目目录时会自动切换版本。这个自动切换是它最实用的地方：不用每次手动 fnm use，也不容易用错版本跑出莫名其妙的构建错误。

验证方法是 fnm list 看已装版本、node -v 看当前生效版本、which node 看实际路径。这里有个关键判断：如果 which node 指向 Homebrew 的路径而不是 fnm 管理的路径，说明 PATH 顺序错了，Shell 里的 fnm 初始化必须排在 Homebrew shellenv 之后。

pnpm 和 Bun：包管理器和运行时怎么分工

Node 装好之后轮到 pnpm。它用硬链接共享依赖，多个项目共用同一份包内容，对 256GB 这种偏紧的机型算是实打实的空间友好。安装时可以通过 fnm 环境下的 corepack enable 启用，也可以全局安装，按你自己的习惯来。

Bun 的定位比 pnpm 更宽，它既是运行时也是包管理器，还带测试和打包能力。建议把它当成按需工具，而不是直接替换 Node。有些项目的依赖在 Bun 下能跑，有些原生扩展仍然会翻车，尤其是涉及 Node 原生模块的包。

下面这张表可以帮你快速理清几个工具的分工，避免重复安装。

Python 与数据库：uv 和 PostgreSQL Client 按需安装

如果你工作里只有很小的 Python 份额，比如偶尔跑个脚本、给 AI 工具搭个环境，那用 uv 就够了。它把 Python 版本管理和虚拟环境两件事合在一起，装依赖比传统流程快不少，也不需要纠结 pyenv 和 venv 的组合用法。

完全不写 Python 的话，这一段直接跳过。开发环境里最大的浪费不是磁盘，而是你花时间维护那些一年用不到一次的工具链。

数据库这块，只连远端数据库的话装客户端就够，没必要在本地跑一个完整的 PostgreSQL Server 常驻占内存和端口。客户端负责连接、查询和导出，不做数据持久化。装完之后用 psql --version 确认命令可用，再用一条连接串测试能否连上远端实例。

这里有个真实的坑：不少人在本地装了 Server 之后忘了关，5432 端口一直占着，之后跑容器化的数据库时报端口冲突，排查半天才发现是本地服务在跑。只用客户端可以彻底避开这一类问题。

IDE 和 API 调试工具：IntelliJ IDEA、Xcode 与 Bruno

编辑器按语言选。写 Java、大型后端项目或者复杂的 Monorepo，IntelliJ IDEA 的索引和重构能力仍然值得那份磁盘占用；写 Node 和前端，VS Code 或者更轻量的编辑器就足够。两边都用的话，注意别让两个 IDE 各自建一套索引目录，那会重复吃掉好几个 GB。

Xcode 只在你真的做 Swift、SwiftUI、StoreKit 或 iOS App 开发时才装完整版，通过 App Store 安装最省心。256GB 的机器上，Simulator Runtime 是最容易被忽略的空间杀手，装一堆用不到的 iOS 版本模拟器，十几 GB 就没了。只在需要时下载对应运行时更合理，DerivedData 也可以定期清理。

API 调试工具建议只留一个。Postman 功能全但偏重，Bruno 相对轻量，请求配置可以随项目放进仓库，适合只调普通 REST 接口的场景。同时装两三个客户端的结果往往是：请求定义散落在不同工具里，同事之间没法共享。

Cloudflare 工具链：Wrangler 走项目级安装，cloudflared 按需装

做 Cloudflare Workers 开发，Wrangler 建议用项目级安装而不是全局安装。原因很实际：项目级安装会把版本锁在 package.json 和 pnpm-lock.yaml 里，团队成员和 CI 用的是同一个版本，不会因为某个人全局升级了 Wrangler 就导致旧项目构建失败。全局工具的问题在于它天然和项目脱钩，升级本身是好事，但升级的时机应该由项目决定。如果你还想把这类无服务器方案的架构和成本一起算清楚，可以对照站内这篇独立开发者用 Cloudflare Workers 降低服务器成本的拆解一起看。

cloudflared 则相反，是按需安装的。只有在需要 Cloudflare Tunnel 把本地服务暴露出去、或者做内网穿透时才装。装上之后建议记一下它用的配置文件和凭据位置，重装系统后凭据需要重新生成，提前知道这点能省掉一次折腾。

256GB 机型的磁盘管理：删什么、留多少

重装只是起点，能不能长期维持一个干净环境，取决于你平时怎么清。pnpm store 会随着项目增加不断变大，定期执行 pnpm store prune 可以清掉不再被引用的包内容。这个操作是安全的，只是下次安装同样的包需要重新下载。

node_modules 是另一个大头。长期不碰的老项目可以直接删掉整个目录，需要时重新安装即可，代码本身在 Git 里不会有任何损失。要找出谁最占空间，用 du 配合查找命令按目录排序，比在访达里一个个点开快得多。

至于空间阈值，来源作者的经验是长期至少留 30GB 可用、尽量维持 40 到 50GB 空闲。这个数字和机器配置、工作内容强相关，做 iOS 开发和大数据量构建的人需要留得更多，纯写脚本和服务端代码的人可以更宽松。把它当作参考区间而不是硬标准，最终以你实际遇到的空间告警为准。

常见错误与自检清单

配置过程中踩的坑高度集中，下面这些几乎每次都有人遇到。

配完之后做一次整体自检：新开终端，依次执行 brew --version、git --version、fnm list、node -v、pnpm -v，全部有正常输出，说明底座没问题。这一步花两分钟，能把大部分环境问题挡在写代码之前。

回滚方案：配置改错了怎么退回可用状态

开发环境的改动大多可逆，关键是别在同一个终端会话里一路改到底、出问题才发现找不到回头路。

改 dotfile 之前先复制一份。动 ~/.zshrc 或 ~/.zprofile 之前，执行一次 cp ~/.zshrc ~/.zshrc.bak，真把初始化顺序改乱了，直接覆盖回来再新开窗口即可。Shell 配置的问题几乎都能靠这个办法在一分钟内解决。

装错版本不要硬扛。如果 Homebrew 装成了 Intel 版本，或者某个全局 CLI 版本和项目冲突，用 brew uninstall 卸掉再按 ARM64 方式重装，比在 PATH 里来回打补丁干净得多。fnm 管理的 Node 也一样，fnm uninstall 掉不用的版本再重装，别让多个版本长期并存。

项目依赖出问题就回到锁定文件。pnpm 项目里删掉 node_modules，用 pnpm install --frozen-lockfile 按 pnpm-lock.yaml 重新装一遍，通常能把「同事能跑我不能」的情况拉回一致状态。这一步不会动你的源代码。

最后的兜底是重装。如果环境已经乱到无法定位，考虑到本文的前提就是重装系统，再重来一次并严格按顺序走，往往比继续排查更省时间。前提是你已经做好了前面说的备份。

什么时候不该在本地折腾：把长期服务放到 VPS 上

本地开发机的定位是「写代码和调试」，不是「长期跑服务」。很多人习惯在本机开一个 Node 进程常驻，笔记本一合盖、Mac mini 一重启，服务就断了。这类场景更适合放到 VPS 上。

PM2 就是一个典型的服务端工具，它的价值在于进程守护和开机自启，在本地开发机上意义不大。如果你想把 Node.js 或 NestJS 服务长期跑起来，选一台海外 VPS 是常见做法，搬瓦工（BandwagonHost）和 RackNerd 都属于国内用户比较熟悉的选择；想更接近云原生体验，Vultr 和 DigitalOcean 的开通流程也比较直接。具体机型、线路和价格变化较快，务必以官网当前页面为准。

判断标准其实很简单：需要 7×24 小时在线、需要固定公网入口、需要部署后不受本机关机影响的服务，就放 VPS；只在开发过程中临时跑一下的，留在本地即可。如果你还在纠结托管形态怎么选，可以看看站内这两篇：共享主机、VPS、云服务器和独立服务器怎么选，以及在 Debian 云服务器上自托管 AI 编码助手的部署与运维指南。把本地和服务端这两类需求分清楚，你的 Mac mini 会干净很多，服务器侧也更稳定。

风险提醒：动手前需要人工核实的几件事

重装系统本身是不可逆操作，所有的准备和备份都是为了兜住这个风险。动手之前请确认：本机还有没有没同步到云端的文件、密钥、证书；重要项目的 Git 仓库是否已经推到远端；有没有正在本机跑、别人还在依赖的临时服务。

磁盘阈值需要按自己情况判断。30GB 可用、40 到 50GB 空闲这个区间来自来源作者的个人经验，不是官方标准，做 iOS 开发、跑大型构建或本地存数据集的人要留得更多。

工具的命令和路径请以官方文档为准。Homebrew 的安装脚本、/opt/homebrew 前缀、各 CLI 的初始化语句都可能随版本更新，本文写的是通用思路，落地时对照官网最新说明。

涉及服务器采购的部分要格外谨慎。文中提到的 VPS 品牌只作为场景示例，机型、价格、线路、优惠和库存随时可能调整，本文没有、也不应该作为购买依据，请直接看官网当前信息。

结论：一份可以直接执行的行动清单

M1 Mac mini 重装后的环境配置，难点从来不在某条命令，而在于「装什么、不装什么、装在哪一层」。按优先级排下来，建议这样的顺序：先装 Xcode Command Line Tools，再装 Homebrew 并配好 PATH；接着配 Zsh、Oh My Zsh 和 Git 加 SSH；然后用 fnm 管 Node、用 pnpm 管依赖，Bun 和 uv 都按需再说；PostgreSQL 只装客户端，数据库 GUI 和 API 调试工具各留一个；Wrangler 走项目级安装，cloudflared 用到再装。

最后留一个习惯：每装一个全局工具之前问自己一句，这个工具三个月后还会用吗？答案是否定的，就别装。环境干净不是一次重装换来的，是每次做减法攒出来的。

现在可以打开终端，从 xcode-select --install 开始，一步一步把环境搭起来。每装完一个工具顺手验证一条命令，别攒到最后一起排查；遇到报错先按上面的回滚方案退回上一步，再决定是继续还是重来。把这份清单存下来，下次换机器或再重装时能直接用。