投研帮1. 准备工作：为什么要在 WSL 2 里装 brew，而不是直接装双系统
这事儿得先掰扯清楚。很多人一听到“Windows 上装 brew”，第一反应是“那不是 Mac 的包管理器吗？”确实，brew 最早是 macOS 上的东西，但后来项目组加了对 Linux 的支持，也就是 Homebrew on Linux，官方缩写叫 linuxbrew。现在你在 GitHub 上看到 homebrew 仓库，里面同时维护着 macOS 版和 Linux 版，WSL 2 里的 Ubuntu 就是一个标准的 Linux 发行版，所以完全可以直接安装使用。
那问题来了：装 Linux 用 brew，跟你直接在 Windows 上装个 Git Bash、Scoop 或者 Chocolatey 有什么本质区别？
我个人的体验是：WSL 2 提供的是一个完整的 Linux 内核，而不是模拟环境。这意味着你在里面装的软件、跑的脚本、编译的 C 项目，行为和你在一台真正的 Linux 服务器上几乎一致。我自己踩过最大的坑就是，很多东西在 Git Bash 下跑得通，一到服务器就崩，因为 Git Bash 不是真 Linux，它没有完整的系统调用层，也没有 systemd（虽然 WSL 里 systemd 也是后来才支持的），很多依赖系统底层的工具根本没法正常工作。WSL 2 用的是真正的 Linux 内核，加上 brew 在 Linux 下的支持已经非常成熟，这套组合基本可以无缝把你的开发环境从 Mac 迁移过来，或者在 Windows 上体验完整的 Linux 开发流。
如果你是个前端、后端、运维或者学生党，需要在 Windows 上跑 Linux 生态的开发工具链，这套方案非常适合你。不用装双系统重启切环境，不用折腾虚拟机分配内存，直接在 Windows 桌面上开一个 Ubuntu 终端，把 brew、git、node、python、openjdk 这些统统交给 brew 管理，舒服得一匹。
那为什么不直接装双系统？两个原因。第一，重启切换成本太高，开发过程中频繁切换系统非常影响效率；第二，双系统的磁盘空间利用率低，Windows 和 Linux 各自需要独立分区，还得处理引导问题，出一次事故你可能大半天就没了。WSL 2 本质上是一个轻量级虚拟机，但它和 Windows 文件系统互通，你可以在 /mnt/c 直接访问 Windows 盘符，也可以在 Windows 里用 \\wsl$ 访问 Linux 文件系统，这一点对日常开发来说太重要了。
好，动机说清楚了，下面直接进入正题。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. WSL 2 环境准备：Windows 功能启用与内核更新
在安装 brew 之前，必须先有一个能用的 WSL 2 环境。很多人卡在第一步，就是 WSL 2 的启用和内核更新没做好。这里我按 Windows 10 和 Windows 11 分别说，两条路线的操作基本一致，只有少量差异。
2.1 启用 Windows 的 WSL 功能
第一步，打开“控制面板 - 程序和功能 - 启用或关闭 Windows 功能”，勾选以下三样：
- 适用于 Linux 的 Windows 子系统（也就是 WSL 功能本身）
- 虚拟机平台（WSL 2 的核心依赖，不勾这个只能跑 WSL 1）
- Hyper-V 管理器（如果你用的是 Windows 10 专业版/企业版，建议勾上；Windows 11 家庭版没有 Hyper-V 也可以，因为 WSL 2 的虚拟机平台是独立于 Hyper-V 的）
这里有一个非常重要的小细节：如果用命令行方式安装，只需要一条命令就能装好 WSL 功能，不需要手动去控制面板勾选。
我自己实际操作下来，最快的路径是在 管理员权限的 PowerShell 里直接跑：
powershell复制wsl --install
这条命令会一次性帮你启用所有必需的 Windows 功能（包括虚拟机平台和 WSL），然后自动下载并安装默认的 Ubuntu 发行版。第一次跑完会提示你重启电脑，重启之后继续按提示设置 Linux 用户名和密码就行。
但注意，这个命令在 Windows 10 上可能不会自动下载内核，如果重启后 wsl --status 提示内核版本太旧，你需要手动更新。Windows 11 基本是开箱即用，Windows 10 的坑要多一些。
2.2 手动更新 WSL 2 Linux 内核
如果你在 Windows 10 上运行 wsl --set-version <发行版名> 2 时提示需要更新内核，或者 WSL 2 启动报 Please enable the Virtual Machine Platform，那就需要手动安装 WSL 2 的内核更新包。微软官方的更新包是一个 .msi 文件，直接到微软官方文档里搜“WSL 2 Linux 内核更新包”就能找到 Windows 版下载链接。
下载之后一路下一步，装完后在管理员 PowerShell 里执行：
powershell复制wsl --set-default-version 2
把默认版本设成 WSL 2。为什么要设默认版本？因为如果 Windows 上同时存在 WSL 1 和 WSL 2 的发行版，你不指定版本的话，新装的发行版默认走的是 WSL 1，性能差距明显，特别是磁盘 I/O 差好几倍。这个坑我帮身边朋友排查过不知道多少次，每次都是因为漏了这条命令。
顺带提一嘴：WSL 2 的文件系统性能和虚拟机磁盘文件（vhdx）息息相关。如果你发现 WSL 2 占用磁盘越来越大且无法自动回收，可以在 Windows 的命令行里执行 wsl --shutdown，再在 PowerShell 里用 Optimize-VHD 手动压缩 vhdx 文件（需要管理员权限）。这个属于进阶操作，后面有空可以单独写一篇，今天先放这儿。
2.3 安装一个你顺手的 Linux 发行版
WSL 默认会装 Ubuntu，但如果你不喜欢 Ubuntu，也有其他选择。wsl --list --online 可以看到所有支持的发行版列表，包括 Debian、Kali Linux、openSUSE 等。我个人推荐新手用 Ubuntu 22.04 LTS，原因是社区资料最多、遇到问题最容易搜到解决方案；如果你喜欢滚动更新的软件库，Debian sid 或者 ArchWSL 也可以考虑，但折腾成本会高不少。
安装发行版也很简单：
bash复制wsl --install -d Ubuntu-22.04
如果你之前已经装了某个发行版，也可以直接继续用，brew 的安装方式在几乎所有主流 Linux 发行版上都一样，只是系统依赖包名字不同罢了。
安装完成并首次启动后，进入到 Linux shell，第一件事就是更新软件源和系统包：
bash复制sudo apt update && sudo apt upgrade -y
然后装编译依赖。brew 在 Linux 上安装很多包时，经常会因为缺系统级依赖而失败，比如 gcc、make、build-essential、curl、git、file 等。提前装好能省掉很多后续麻烦：
bash复制sudo apt install -y build-essential procps curl file git
这几个包除了 build-essential 是编译工具链，procps 提供 ps 命令（brew 的安装脚本依赖它检测系统进程），file 用来识别文件类型，git 和 curl 是 brew 安装和下载源码包的基础。少了任何一个，安装过程中都可能在某个角落炸一下。
3. 安装 Homebrew：一行命令背后的原理与排错
环境搞定后，就可以开始装 brew 了。但在敲命令之前，我建议你先理解一下 brew 的安装脚本做了什么，这对你后面排错非常有帮助。
3.1 Homebrew 安装脚本背后做了什么
brew 官方推荐的安装命令是：
bash复制/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"
这条命令咋一看是“下载一个脚本然后执行”，但脚本内部实际做了以下几件事：
- 检查系统环境：确认系统是 macOS 还是 Linux，根据系统选择安装路径。在 Linux 上，brew 默认装在
~/.linuxbrew或/home/linuxbrew/.linuxbrew（取决于你的用户权限），并创建必要的目录结构。 - 安装依赖包：脚本会检查
curl、git、build-essential等依赖是否已安装，缺什么就尝试通过系统的包管理器装什么。 - 克隆 Homebrew 仓库：从 GitHub 上克隆
homebrew/core仓库到本地。这一步是安装过程中最耗时、最容易失败的一步，因为 raw.githubusercontent.com 在国内的访问速度并不稳定，超时或中断会导致安装看似“卡住”或直接报错。 - 设置环境变量：在
~/.bashrc（或~/.zshrc）中追加初始化代码，让每次打开新终端都能自动把 brew 加入环境变量。
理解了这些，你就知道为什么很多人安装失败都集中在“如何下载 Homebrew 仓库”这一步——不是脚本逻辑问题，纯粹是网络问题。
3.2 实测好用的安装方式：Gitee 镜像脚本
如果你直接跑官方脚本失败了，别气馁，这是非常常见的情况，而且解决方案早就成熟了。中科大和清华都有 Homebrew 的镜像源，但最简单的方式是使用一个现成的镜像安装脚本，它把安装过程里的 GitHub 下载链接替换为了 Gitee 上的同步仓库，再配合中科大或清华的二进制源，速度非常快。
我实测可用的方式是，先拉取一个开源镜像脚本（在 GitHub 上有多个仓库做了这件事，选一个大家用得多、星标高的就行），然后执行：
bash复制/bin/bash -c "$(curl -fsSL https://gitee.com/cunkai/HomebrewCN/raw/master/Homebrew.sh)"
这个脚本会让你选择下载源，一般选“中科大”或“清华”都行，选完它自动完成克隆和环境变量配置。整个过程大概几分钟，速度比官方脚本稳定太多。
不过这里要说明一下：这种第三方镜像脚本的版本可能会有更新，如果链接失效，直接去搜“brew 国内安装脚本”找最新可用的即可。核心思路没变：把 GitHub 的源换成国内镜像源。
3.3 环境变量配置与验证
安装完成后，你需要确认环境变量是否正确加载。如果你用的是 bash，查看 ~/.bashrc，你会看到类似下面的内容被追加到了底部：
bash复制export HOMEBREW_BREW_GIT_REMOTE="https://mirrors.tuna.tsinghua.edu.cn/git/homebrew/brew.git"
export HOMEBREW_CORE_GIT_REMOTE="https://mirrors.tuna.tsinghua.edu.cn/git/homebrew/homebrew-core.git"
export HOMEBREW_BOTTLE_DOMAIN="https://mirrors.tuna.tsinghua.edu.cn/homebrew-bottles"
这三行就是 brew 国内加速的三板斧：
HOMEBREW_BREW_GIT_REMOTE：brew 本身的 Git 仓库地址HOMEBREW_CORE_GIT_REMOTE：brew 的 formula（安装脚本）仓库地址HOMEBREW_BOTTLE_DOMAIN：预编译二进制包的下载源地址
设置完执行 source ~/.bashrc，然后输 brew --version 验证。如果输出类似于：
code复制Homebrew 4.x.x
Homebrew/homebrew-core (git revision xxxx; last commit xxxx)
说明安装成功。
还有个小细节要提醒：如果你用的不是 bash 而是 zsh，环境变量要追加到 ~/.zshrc 里，不然新终端打开还是不识别 brew 命令。这个坑特别隐蔽，因为很多人装完 brew 后开新终端就报 command not found，一查才发现 shell 不对。
4. brew 安装核心工具实战：Java、Node、Git、pnpm 一网打尽
brew 在 Linux 上安装软件的方式和 macOS 基本一致，只是软件库略有差异。下面我挑几个我日常用得最多的工具，演示一下从安装到配置的全过程，这样你照着走一遍，就能掌握 brew 的核心用法。
4.1 安装 Git 并配置全局用户信息
Ubuntu 通常自带 Git，但版本可能比较旧。用 brew 装一个新版的好处是版本更新、且不会跟系统自带的冲突：
bash复制brew install git
注意 brew 装的 git 会链接到 /home/linuxbrew/.linuxbrew/bin/git，要先确认这个路径在 $PATH 中排在了 /usr/bin/git 前面。可以用 which git 查看当前生效的是哪个。如果发现还是系统自带版本，就需要调整 ~/.bashrc 中的 $PATH 顺序，把 brew 的路径放在前面。
装完记得配置用户信息：
bash复制git config --global user.name "你的名字"
git config --global user.email "你的邮箱"
这一步大部分人觉得无所谓，但如果你不配，后面 commit 时会被 Git 反复提醒，而且在 GitHub 上提交记录不会关联到你的账号。
4.2 用 brew 安装 Node.js（版本管理推荐 nvm + brew 组合）
brew 装 Node 非常简单：
bash复制brew install node
默认装的是当前最新的 LTS 版本。装完验证：
bash复制node -v
npm -v
如果你需要在多个 Node 版本之间切换，我个人更推荐先用 brew 安装 nvm：
bash复制brew install nvm
然后创建 nvm 的工作目录，并在 shell 配置文件中加载 nvm：
bash复制mkdir ~/.nvm
export NVM_DIR="$HOME/.nvm"
source "/home/linuxbrew/.linuxbrew/opt/nvm/nvm.sh"
这样你就有了一个既能用 brew 管理全局工具链、又能用 nvm 灵活切换 Node 版本的组合方案。实际开发中很爽：全局默认 Node 版本用一个稳定的，项目需要新特性或老兼容性时随时 nvm install 一把梭。
4.3 brew 安装 pnpm 及其性能优势
除了 npm，现在是 pnpm 的天下。ppnpm 的好处一个是磁盘空间复用优化、另一个是安装速度更快，这在单体仓库（monorepo）里优势特别明显。用 brew 安装：
bash复制brew install pnpm
安装完成后，跑一下 pnpm --version 验证。理论上，当你执行 pnpm 后，首次使用时可能会提示是否设置 corepack 或配置 npm 全局路径之类的问题，但 brew 装好的版本已经把这些配置简化了，基本开箱即用。
如果你是老旧 Node 版本用户，建议升级 Node 后再装 pnpm，因为新版 pnpm 对 Node 版本的最低要求是 16 以上，这是容易忽略的坑。
4.4 brew 安装 Java（OpenJDK）
Java 开发者在 WSL 2 里装 JDK 也是个高频需求。brew 安装 OpenJDK 也很简单：
bash复制brew install openjdk@17
brew install openjdk@21
这里要提醒一下：brew 不会自动帮你设置 JAVA_HOME 环境变量，需要手动找到 JDK 路径，然后把它加到 ~/.bashrc：
bash复制export JAVA_HOME="/home/linuxbrew/.linuxbrew/opt/openjdk@17"
export PATH="$JAVA_HOME/bin:$PATH"
如果你的项目需要在多个 JDK 版本之间切换，建议安装 jenv：
bash复制brew install jenv
jenv 类似 nvm，是管理 Java 版本的工具。用 jenv 全局设置默认 JDK，每个项目目录里再单独指定版本，就不用每次改环境变量了。
你可以看到，brew 在这里扮演的角色是“一个统一的前端包管理器”，它帮你把 Java、Node、Git、pnpm 全都沉淀在同一个环境变量管理体系里，升级、卸载、查看版本都一目了然，不像 Windows 原本那样每个软件有各自的安装器和配置项，管理起来非常割裂。
5. 常见问题与排查技巧：从 A brew install 进程占用到 Docker Desktop 的联动
这一节是全文最值钱的部分，因为我在这个环境上踩过的坑，几乎没有一篇教程一次性讲全过。
5.1 a brew install gif process has already locked 如何排查
这个报错是 brew 多实例冲突的经典错误。它的背景是：brew 在安装、升级、卸载时，会在 /tmp 下创建一个锁文件，如果同时在多个终端里跑了 brew 命令，或者上次安装意外中断、锁文件没被清理，新的 brew 进程就会检测到“已经有 brew 进程在操作”并拒绝执行。
报错类似：
code复制Error: Another active Homebrew process is already in progress.
解决办法很简单，但需要分情况：
- 如果你确实在另一个终端跑了
brew install，等它跑完就行，别强行杀掉。 - 如果是上次中断留下的残留锁，直接删除锁文件。brew 的锁文件通常位于
/tmp/brew.lock或/home/linuxbrew/.linuxbrew/var/homebrew/locks，删掉再重试：
bash复制rm -f /tmp/brew.lock
rm -f /home/linuxbrew/.linuxbrew/var/homebrew/locks/*
如果删掉之后还报错，说明有僵尸进程残留，那就再查一下：
bash复制ps aux | grep brew
sudo kill -9 <PID>
很多用户第一次遇到这个错误会慌，其实它本身对数据没有破坏性，只是 brew 的并发保护机制。理解了这个机制，下次就不会再犯了。
提示：永远避免在多个终端同时运行
brew install。如果确实需要批量安装，写成一个 shell 脚本顺序执行，比并行执行要安全得多。
5.2 brew 安装软件时卡死或下载慢
这个问题几乎人人都会遇到。前面说了，网络环境决定了 clone 仓库和下载 bottle 包的速度。如果你没有配镜像源，直接把官方源换成国内镜像，多数“卡死”就解决了。
但如果你已经换好镜像还是慢，那就是个别包走的是 GitHub Releases 下载，不是走 bottle 源。比如某些 formula 在 install.rb 里 hardcode 了一个 GitHub Releases 下载 URL，这种你只能等，或者手动下载好放入 ~/Library/Caches/Homebrew/downloads（Linux 路径是 ~/.cache/Homebrew/downloads），brew 发现本地已有缓存就会跳过下载。
我也试过直接在 brew 的 formula 里改 URL 替换成镜像来源，但对于普通使用者而言，这个操作成本过高，不推荐。日常经验是：大多数包都会走 bottle 二进制下载，速度完全可以接受；只有极少数源码编译或 GitHub Releases 的包才慢。
5.3 WSL 2 与 Docker Desktop 的视角：不要选 Hyper-V 模式
有 Docker 需求的人一定会关心：Docker Desktop 在 Windows 上跑，WSL 2 到底是什么角色？
先说结论：安装 Docker Desktop 时，引擎选项务必选择 Use WSL 2 based engine，而不是 Hyper-V 模式。
原因有几个：
- 性能：WSL 2 的 Docker 引擎启动更快，内存占用更小，跨文件系统访问更高效。
- 体验：当你选了 WSL 2 后端，Docker Desktop 会自动集成到 WSL 2 的发行版里。比如你打开 Ubuntu 的 WSL 终端，直接敲
docker ps就能和 Windows 侧的 Docker 引擎通信，不用额外装 docker-cli。 - 兼容性：Hyper-V 模式和公司电脑、虚拟机软件共存的冲突概率更高（比如 VirtualBox 和 VMWare 不兼容），WSL 2 模式冲突少很多。
如果你已经装了 Docker Desktop 且用的是 Hyper-V 模式，想切换到 WSL 2：打开 Docker Desktop -> Settings -> General，勾上 “Use the WSL 2 based engine”，然后在 Resources -> WSL Integration 里把要集成的发行版打开（我一般只开 Ubuntu），最后 Apply & Restart。实测切换后，Docker 容器启动速度快了一大截。
有人会问，那 WSL 2 里的 brew 装 docker 工具链有用吗？当然有用。你可以在 WSL 2 里用 brew 装一些 Docker 的辅助工具，比如 docker-compose、docker-buildx、kubectl、helm 等。这些工具链装好后，直接通过 WSL 2 的终端操作 Docker 引擎，比在 Windows PowerShell 里手动配置 PATH 要干净得多。
5.4 brew upgrade 升级后软件不再工作怎么回退
用 brew 时间长了，总会遇到“今天一升级，某个依赖出现兼容性 bug”的情况。比如 OpenSSL 版本升级导致老的 Ruby 项目崩了、Node 升级导致某个 native 模块需要重新编译等。
brew 提供了一个很实用的回滚机制：
bash复制brew log <formula>
brew install <formula>@<旧版本>
例如 brew install openjdk@11 这种带版本号的包，可以直接切。如果你的 formula 没有带版本号的旧包，那就要用 brew revert（新版 Homebrew 支持这个子命令）。
bash复制brew revert <formula>
它会让你选择要回退到哪一个 commit，选完后 brew 会下载对应版本的源码或 bottle 重新安装。这个功能是救命级别的，特别是你发现自己升级完某个核心工具导致一堆项目跑不起来的时候。
操作顺序：先 brew log 看看最近升级前有哪些版本，再 brew revert 选一个稳定版本，回到原来的状态。升级前养成好习惯，先把 brew list --versions 输出保存一份，回退的时候有依据。
6. 环境验证与性能调优：让 WSL 2 与 brew 更顺畅协同
装好环境后，如果不做任何调整直接高强度开发，你可能会遇到两个问题：内存占用高、文件读写慢。这两个问题虽然不直接影响 brew 安装，但会显著影响你的整体开发体验，这里备份几个亲测有效的调优手段。
6.1 控制 WSL 2 的内存与 CPU 使用
WSL 2 有一个配置文件：C:\Users\<你的用户名>\.wslconfig。没有就新建一个，这是 Windows 侧的全局配置。
举一个我实际使用的配置：
ini复制[wsl2]
memory=6GB
processors=4
swap=2GB
localhostForwarding=true
要点解释：
memory：WSL 2 能使用的最大物理内存。默认情况下，WSL 2 会吃掉你 Windows 机器 50% 的内存，如果你有 32GB 内存可能还没啥感觉；如果你只有 16GB，建议限到 8GB 以下，不然 Windows 经常卡成幻灯片。processors：限制 WSL 2 占用的 CPU 核心数。默认也是占满所有逻辑核心，对于多任务用户来说留出 2 个核给 Windows 更有余裕。swap：给 WSL 2 的虚拟内存，如果编译大项目内存不够，swap 能避免进程直接被杀掉。
改完配置后，在 PowerShell 里执行 wsl --shutdown，再重新进入 WSL 2 就能生效了。我见过不少用户改完配置不执行 shutdown，然后抱怨“怎么没有效果”，其实是没有重启 WSL 实例。
6.2 把项目放在 Linux 文件系统而不是 /mnt/c
还在 WSL 2 里从 /mnt/c/Users/xx/... 直接进入你在 Windows 上的项目目录？我强烈建议你换个做法。
原因：WSL 2 访问 Windows 文件系统是跨文件系统访问，速度慢一个量级。尤其是在跑 npm install、pnpm install、composer install 等大量小文件读写的场景，/mnt/c 路径下的安装速度能比 Linux 文件系统里慢 5~10 倍。
所以，强烈建议你的代码项目放在 Linux 文件系统内部（比如 ~/projects 或者 ~/code），Windows 侧再通过 \\wsl$\Ubuntu\home\<用户名>\projects 访问。这样两边都能操作，但是跑在 Linux 侧的是原生速度。
用 brew 安装的 Node、pnpm 等工具，在 /mnt/c 下创建 node_modules 时特别容易出问题：包下载了，但文件权限乱了，或者链接（symlink）创建失败——因为 Windows 文件系统的符号链接需要管理员权限。这些坑大多都能通过把项目挪进 Linux 文件系统避免。
6.3 WSL 2 与 Windows 剪贴板、端口访问的自动化
WSL 2 有一点很爽：它天然支持端口转发，localhost 互通比 WSL 1 做得更好。你在 WSL 2 里起了一个开发服务器，监听 8080 端口，在 Windows 浏览器直接访问 http://localhost:8080 就能看到页面。这对前端开发特别顺手，不用记 IP 地址。
如果你需要给其他电脑访问 WSL 2 里的服务，需要用 netsh interface portproxy 做端口转发，这里就不展开细节了，等到有这个需求时你能搜到专门教程。
剪贴板方面，WSL 2 默认支持双向剪贴板共享，前提是 Windows 版本较新（Windows 11 22H2 以上）。如果你发现剪贴板不互通，检查一下 Windows 与 WSL 的更新版本，老版本的内核/系统确实会有这问题。
7. 额外扩展：brew 在 WSL 2 中的其他实用玩法
前面讲的是安装与基础用法，其实 brew 在 WSL 2 里的可能性还有很多。这里补充几个我觉得值得去试的扩展用法。
7.1 用 brew 搭建一套“跨平台开发环境”
我觉得 brew 在 WSL 2 里最大的价值，是帮你实现“一份 brew 配置，跨设备复用”。你在 Mac 上用过 brew，WSL 2 里的 brew 命令、仓库、配置文件基本一致。这意味着你可以把 Brewfile 到处迁移：Mac 和 WSL 共用同一套开发工具清单。
举个例子，你可以在 ~/Brewfile 里写上：
code复制tap "homebrew/bundle"
brew "git"
brew "node"
brew "pnpm"
brew "openjdk@17"
cask "docker"
然后一次安装全部工具：
bash复制brew bundle --file=~/Brewfile
这样在新机器上只需要装好 WSL 2 + brew，然后 brew bundle 一键还原开发环境。Mac 用户还能配合 cask 装 GUI 应用，WSL 2 里 cask 大多不适用，但 brew 包部分完全通用。这种可复现的环境管理思路，比手动一个个装工具高效太多。
7.2 用 brew 管理内置服务和应用
除了 dev tools，brew 也能用来管理服务类软件，比如 mysql、postgresql、redis、nginx。在 Linux 版 brew 中，服务的启停是通过 brew services 子命令实现的。
启动 redis：
bash复制brew install redis
brew services start redis
这样 redis 就会在后台常驻，并且开机自启（前提是 WSL 2 里已启用 systemd，或者你在 shell 配置里加载了 brew services 的启动项）。这比手动去 /etc/init.d 或 systemctl 配服务要简单不少，而且所有服务的配置都归拢到 brew 里，管理心智负担小很多。
7.3 利用 brew 分析依赖关系
当你维护的项目多了，系统里包的依赖关系会变得非常复杂。brew 提供了一些很实用的依赖查询命令，帮助你理清关系。
bash复制# 查看某个包的所有依赖
brew deps --tree node
# 查看哪些包依赖了某个包
brew uses redis
# 查看系统中所有已安装包及其依赖状态
brew list --formula --verbose
比如你想清理无用的包，先 brew uses 查一下还有没有其他包依赖它，再用 brew uninstall 干净移除，避免删掉一个包后把别人的依赖也带崩了。
8. 总结与个人建议（踩坑后的一些实在话）
到这里，WSL 2 安装 brew 的完整流程和深度使用就全部讲完了。最后再分享一点我在实际操作中的体会，也许能帮你少走几步弯路。
第一，WSL 2 的体验是慢慢调出来的，不是一次性装完就万事大吉。你刚装好 brew 时，可能感觉和 Windows 自带的工具链差别不大；但当你开始用它管理各种开发依赖、用 brew services 跑数据库、用 Brewfile 一建还原整套环境时，才会真正体会到这套组合的威力。
第二，如果你在 Windows 上有 Windows Subsystem for Linux 的权限问题（比如启动报 0x8007019e、0x80070003 之类的错误），多数情况下是旧版本的 WSL 内核导致的，先把 WSL 更新到最新版本再试，比排查各种玄学问题都有效。
第三，也是最实在的一点：brew 国内镜像源偶尔也会失效或同步延迟。如果你安装了某个包之后，brew update 报错说无法解析镜像地址，不是环境问题，是镜像源临时抽风，等一等换个镜像（中科大和清华交替用）就好。这个我在过去半年里至少遇到三次，心态放平就好。
最后再分享一个小技巧：如果你决定长期在 Windows 上做 Linux 开发，强烈建议在 Windows 终端（Windows Terminal）里把 WSL 的 Ubuntu 配置为默认启动项，再把 VS Code 装上 WSL 扩展。这样一来，你打开终端就是 Ubuntu，打开 VS Code 就是远程连到 WSL 2，整个开发流程完全无缝。配合本文装好的 brew，你的 Linux 开发环境基本就齐活了。