Mac入门开发者环境搭建

先跑通项目，再按需求补齐工具

Windows 转 Mac：开发环境搭建与工具选择

面向从 Windows 转到 Mac 的开发者：先完成系统与命令行基础，再按项目配置 Git、语言环境、编辑器、容器与 AI 工具。FreeMac 帮你分清哪些先装、哪些等需要再加。

·更新于 ·阅读约 12 分钟·计算中...·入门 → 进阶
Windows 转 Mac：开发环境搭建与工具选择

换到 Mac 后，最容易浪费时间的事，是第一天就把 Windows 上见过的工具全装一遍。

FreeMac 的选择是：先让一个真实项目跑起来，再为明确需求增加工具。 开发环境是否完成，不由安装了多少 App 决定，而是取决于你能否拉取代码、安装依赖、启动项目，并留下一个可推送的 Git 提交。

这篇面向从 Windows 转到 Mac 的开发者。开头的系统设置也适合普通用户；从“最短开发路径”开始则按项目需要阅读。软件版本、许可和功能会变化，本文的链接以官方说明为准，核验日期为 2026-09-06。

先决定在哪一节停下。 只想把新 Mac 调整顺手，读完“先让 Mac 顺手”即可；日常开发读到“验证一个真实项目”；Docker、本地模型和终端美化都不是第一天的必修课。

先让 Mac 顺手

这部分只保留会影响迁移体验的设置。更完整的日常迁移流程可以看 Windows 转 Mac 完整路线图。

触控板、Finder 与截图

  • 在“系统设置 → 触控板”开启“轻点来点按”；是否关闭自然滚动，按自己的习惯决定。
  • Finder 中开启“显示所有文件扩展名”“显示路径栏”和“显示状态栏”。项目目录、隐藏配置文件和文件类型会更容易辨认。
  • 记住 ⌘ + Shift + 4 截选区，⌘ + Shift + 5 打开截图和录屏面板；保存位置也在这里调整。
  • Windows 用户常需要窗口分屏。当前 macOS 已提供窗口平铺；只有想要固定快捷键、更多布局或跨显示器规则时，再安装 Rectangle 或使用 Raycast 的窗口管理。Apple 官方说明

输入法与文件迁移不要混进开发环境

中文输入、移动硬盘、浏览器书签、密码和微信文件都很重要，但它们不是开发环境的一部分。遇到这些问题，分别看 Mac 中文输入法对比、Mac 系统设置完整指南 和路线图即可。这样不会因为准备开发环境，顺手堆进一串不必要的软件。

FreeMac 的最短开发路径

下面五步适用于大多数语言和框架。每走完一步先验证，再继续下一步。

  1. 安装 Command Line Tools 与 Homebrew。
  2. 配置 Git 身份和仓库认证。
  3. 根据当前项目选择语言版本和包管理器。
  4. 选择一个编辑器，打开并运行项目。
  5. 提交一次变更；至此开发环境已经可用。

1. Command Line Tools 与 Homebrew

先安装 Apple 的 Command Line Tools；它提供 Git、编译工具和许多安装器需要的基础能力：

命令
xcode-select --install

完成安装后，从 Homebrew 官网 获取安装命令：

命令
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

安装器结束时会输出一段“Next steps”。务必复制它给出的 brew shellenv 命令。 Apple Silicon 通常使用 /opt/homebrew，Intel Mac 通常使用 /usr/local；不要把别人机器的路径直接抄进自己的配置文件。

重新打开终端后验证：

命令
brew --version

网络慢时再配置镜像

先尝试官方安装。只有 GitHub 或下载确实失败、缓慢时，再使用可信镜像站的当前指引。例如中科大 Homebrew 镜像说明同时覆盖安装脚本、API 和 bottles。镜像不是永久必装配置；网络恢复后也应知道如何恢复官方源。

FreeMac 怎么看： Homebrew 是开发基础设施，不是“Mac 必装软件榜”的一员。你只需要用它安装项目需要的工具，不需要为了凑清单安装一长串 cask。

2. Git：身份不等于登录

通过 Homebrew 安装 Git，配置提交署名：

终端 · zsh
brew install git
git config --global user.name "Your Name"
git config --global user.email "you@example.com"
git config --global init.defaultBranch main
git --version

user.name 和 user.email 只会写入提交记录，不代表你已经能拉取私有仓库或推送代码。接下来选一种团队约定的认证方式：HTTPS 登录或 SSH key。GitHub 用户可直接按 GitHub SSH 官方指南完成；公司 GitLab、Gitea 或自建平台则跟随团队文档。

如果你使用代理，不要照抄固定端口。只在自己的代理确实需要时设置 Git 的 http.proxy 和 https.proxy，并保留取消配置的方法：

终端 · zsh
git config --global --unset http.proxy
git config --global --unset https.proxy

3. 语言与包管理器：项目优先

不要先问“Mac 上最好的 Node 是什么”，先看项目仓库：.nvmrc、package.json 的 engines、packageManager 字段、README 和锁文件，才是这个项目应该使用的版本与工具。

Node.js 项目

新项目可以选择当前 LTS；截至核验日，Node 24 是 LTS，Node 22 已进入维护期。已有项目仍然优先遵循项目要求，而不是一律升级。可使用 fnm 管理多个 Node 版本：

终端 · zsh
brew install fnm
echo 'eval "$(fnm env --use-on-cd)"' >> ~/.zshrc
source ~/.zshrc

# 示例：新项目选择当前 LTS；已有项目替换为项目要求的版本
fnm install 24
fnm default 24
node --version

包管理器也遵循项目已有选择：

仓库里看到的文件使用什么
package-lock.jsonnpm
pnpm-lock.yamlpnpm
yarn.lockYarn
bun.lock 或 bun.lockbBun

新项目想用 pnpm 时，优先用 Corepack 管理，而不是随手全局安装一个版本：

终端 · zsh
corepack enable
corepack prepare pnpm@latest --activate
pnpm --version

其他语言

Python、Go、Rust、Java 和 .NET 都应随项目需求安装，不需要新 Mac 第一天全部装好。优先采用项目 README 或官方安装说明；语言版本管理工具同样应由团队约定决定。

npm 镜像的正确位置： 先安装 Node，确认 npm --version 可用，再按网络情况设置镜像。镜像是网络方案，不是每个 Node 项目的固定配置；公司私有源或锁文件可能另有要求。

4. 编辑器与终端：选一个能完成工作的组合

VS Code 是稳妥的起点：

命令
brew install --cask visual-studio-code

Cursor 可以作为 AI 辅助编辑器试用，但不需要与 VS Code 同时作为主力。先让一个编辑器能打开项目、识别语言、运行终端和调试，再考虑同步设置或迁移扩展。

macOS 自带 Terminal 已足够完成开发。iTerm2、Warp、Starship 和主题都属于提高舒适度的选择，不应阻塞项目启动。

FreeMac 怎么看： 编辑器不是按“AI 功能最多”选，而是按你是否能稳定打开项目、理解团队配置、运行测试和处理冲突来选。AI 工具是增强，不是开发环境的地基。

5. 用真实项目验证

最好的验证不是盯着版本号，而是用一份真实代码走完工作流：

终端 · zsh
# 以团队仓库为例；替换为你的地址
git clone git@github.com:your-org/your-project.git
cd your-project

# 按仓库锁文件选择 npm / pnpm / yarn / bun
pnpm install
pnpm dev

如果你暂时没有项目，可以创建一个 Next.js 示例，但把它当作 Node 路径测试，不代表所有开发栈都已配置：

终端 · zsh
pnpm create next-app@latest hello-mac
cd hello-mac
pnpm dev

然后完成一次小改动：编辑文件、运行检查或测试、执行 git status，再提交。能在自己的仓库里完成“拉取 → 安装 → 启动 → 提交”，就可以停止继续装基础工具。

按需增加：Docker、AI 与本地模型

这些工具有明确需求时再装，不要把它们当成“开发者身份认证”。

Docker 与本地数据库

项目需要容器时，安装 Docker Desktop。Homebrew 当前的 cask 名称是：

命令
brew install --cask docker-desktop

先启动 Docker Desktop，再用 docker info 确认引擎运行。Docker Desktop 并非所有商业场景都免费：个人、教育、非商业开源，以及符合其规模条件的小企业可免费使用；公司环境应先核对 Docker 订阅说明。

下面的数据库示例仅供本机临时开发，使用了弱密码，并将端口限制在本机：

配置文件
services:
  postgres:
    image: postgres:16-alpine
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: postgres
    ports:
      - "127.0.0.1:5432:5432"
    volumes:
      - postgres_data:/var/lib/postgresql/data

  adminer:
    image: adminer
    ports:
      - "127.0.0.1:8080:8080"

volumes:
  postgres_data:

在包含 docker-compose.yml 的目录启动并检查：

终端 · zsh
docker compose up -d
docker compose ps
docker compose logs --tail=50

停止服务用 docker compose down；默认不会删除数据卷。只在确认不再需要本地数据时，再额外使用 docker compose down -v。

AI 编程工具

Claude Code、Cursor 与其他 AI 工具都可以放在项目已经能运行之后再评估。安装客户端不等于拥有可用服务：Claude Code 需要合适的订阅、Console 账户或受支持云服务访问；团队项目还要遵守代码、密钥与数据处理规则。

Ollama 本地模型

需要在本机运行模型时再安装 Ollama：

命令
brew install --cask ollama

运行已经下载到本机的模型可以在本地完成，但首次下载模型需要网络；Ollama 也提供云功能。对严格本地要求，按其官方 FAQ关闭云功能后再使用。模型大小、量化、内存和上下文长度都会影响实际体验，不用“某一代 Mac 一定流畅”的口号代替测试。

常见卡点

现象先检查什么
brew: command not found回看安装器的 Next steps，确认已执行本机路径对应的 brew shellenv，再重新打开终端
Node 版本不对检查 .nvmrc、engines 与 fnm 当前版本，而不是先全局升级
pnpm install 失败确认仓库本来就使用 pnpm；检查 Node 版本、网络和公司私有 registry
Git 无法 push区分提交署名与仓库认证；检查 HTTPS 登录或 SSH key 是否被平台接受
Docker 命令能执行但容器起不来确认 Docker Desktop 已启动，执行 docker info 与 docker compose logs
端口被占用用项目提示或 lsof -i :端口号 找到占用者，再决定停止服务还是换端口

收尾：记录你的可重复环境

当真实项目已经跑通，记录真正需要的工具即可。Homebrew 用户可以导出 Brewfile，并把它和必要的版本说明放在自己的配置仓库中：

命令
brew bundle dump --force --file=~/Brewfile

这不是要求每个人立刻做的优化。它适合已经确认工具组合稳定、希望下次换机快速恢复的开发者。

FreeMac 的结论： 新 Mac 不需要第一天就变成一台“装满工具的 Mac”。先跑通一份真实项目；之后每增加一个工具，都能说清它解决了哪一个实际问题。这才是能长期维护的开发环境。

继续阅读

继续阅读

订阅 FreeMac

每周精选：免费 Mac 软件评测、可信来源更新、替代方案和少折腾指南。

← 返回指南列表