## 安装（精简版）
“`bash
# 先装 prereqs（Debian / Ubuntu）
sudo apt install build-essential procps curl file git
# 装 Homebrew 到 /home/linuxbrew/.linuxbrew
/bin/bash -c “$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)”
# 加到 PATH（安装输出里也有这步）
test -d /home/linuxbrew/.linuxbrew
&& eval “$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)”
# 持久化到 shell rc
echo ‘eval “$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)”‘ >> ~/.bashrc
“`
Fedora / RHEL: `sudo dnf group install “Development Tools” && sudo dnf install procps-ng curl file`。Arch: `sudo pacman -S base-devel procps-ng curl file git`。
**安装路径锁死在 `/home/linuxbrew/.linuxbrew`**。Homebrew 选这个的考虑：
– 预编译 bottles（binary 包）能直接用，不用现编以系统库
– 安装完 Homebrew 永不再写系统目录（`/usr` / `/opt` / `/usr/local`）
– 装完不再需要 root
代价：你不能装到 `/opt/homebrew`（Apple Silicon Mac 路径）或者 `/usr/local`（Intel Mac 路径）。Linux 上固定 `/home/linuxbrew/.linuxbrew`，单用户。
## 值得装的四种场景
### 场景 1 —— Mac 和 Linux 用同一个工具
Mac 工作站 + Linux 服务器（或 WSL）的人用 Homebrew 是经典场景。两台机器跑同一组命令装同一版本：
“`bash
brew install postgresql@16 redis ffmpeg jq yq fd ripgrep
“`
语义两边一致。Mac 上还能写个 `Brewfile`：
“`ruby
# Brewfile
tap “homebrew/bundle”
tap “homebrew/services”
brew “postgresql@16”
brew “redis”, restart_service: true
brew “ffmpeg”
brew “jq”
cask “iterm2”
mas “Xcode”, id: 497799835
“`
然后 Linux 上跑 `brew bundle –global` 也读这同一份。**`Brewfile` 跨 macOS 和 Linux 通用**——只要每个 formula 都有 Linux bottle（绝大多数主流的都有）。
这是 Homebrew on Linux 的招牌场景。如果你不同时用 Mac 和 Linux，你不是这篇的读者。
### 场景 2 —— 要比发行版新一档的工具版本
Debian 13 自带 PostgreSQL 15。Ubuntu 26.04 也是。要 PostgreSQL 17 三条路：(a) 加 PostgreSQL 官方 APT 源（`apt.postgresql.org`）；(b) 从源码编；(c) `brew install postgresql@17`。
“`bash
brew install postgresql@17
brew services start postgresql@17
“`
Homebrew 把 PostgreSQL 17 当 user-level systemd 服务跑。发行版的包管理器完全不知道这事。symlink 全落在 `~/.linuxbrew/bin/`，shell 优先级在最前。
类似「Homebrew 比 apt 新」的常见 case：
– **Node.js**：`brew install node@22` → 22 LTS，不用 nvm
– **Python**：`brew install python@3.13` → 新版 Python 带 `pip`，不用 `pyenv`
– **OpenJDK**：`brew install openjdk@21` → 21 LTS
– **ffmpeg**：Homebrew 版编了比 Debian 版更多的 codec
– **PostgreSQL**：上面说的
### 场景 3 —— 项目级可复现开发环境
`Brewfile` + `brew bundle` 是平台无关的 dotfiles 替换。仓库里 commit 一个 `Brewfile`，`brew bundle` 一行保证每台 `git clone` 后的 Mac / Linux 机器到同一工具状态：
“`bash
git clone https://github.com/myorg/devtools.git ~/devtools
cd ~/devtools && brew bundle
“`
项目根级别 `Brewfile.lock` 配合 `brew bundle –install –no-upgrade` 是可复现 install。
也是 Linux CI image 减重 + 可复现的常见招数。
### 场景 4 —— 用 `brew services` 在 Linux 跑服务（听起来像玩笑，但真有人用）
是的，`brew services` 在 Linux 上能跑。systemd `–user` 模式兜底，没 systemd 就走 launchd 或直接进程。PostgreSQL、Redis、MySQL 都行，`brew services start postgresql@17` 起服务。开发机上同时要跑两个版本的 Postgres 测 schema 升级？apt 一份 postgresql@15 + brew 一份 postgresql@17 同时跑在不同端口。比加多个 apt 源清爽。
## 别装的场景
### 生产服务器别用 Homebrew
Homebrew 的前缀 `/home/linuxbrew/.linuxbrew`。意味着：
– 不在 `/usr/bin`，apt 看不到
– 不在 OS update path 里
– 手动跑 `brew upgrade` 才更新——apt unattended-upgrades 那条路完全用不上
生产 Debian 服务器，**用 Debian 包或项目官方 APT 源**。OS update 流会自动抓安全补丁。Homebrew-prefixed 服务根本不在 OS 包管理器的雷达上。
### 系统级 daemon 别用 Homebrew
部署 nginx / postgres / redis 给”整个机器”用，apt + `systemctl` 集成得更好，可审计性也强。Homebrew user-level 服务适合**开发流**，不适合生产。
### 别把它当唯一工具
apt 是底层（你一定有）。加 Homebrew 等于**两个包管理器、两套更新节奏、两种心智模型**。要走这条路先承认自己在维护两套工具链，apt 这边会自动更新。
合理的分层：**apt 管 OS 层**（内核附近的库、桌面、网络 daemon、libreoffice），**brew 管开发层**（postgresql@17、node@22、新版 ffmpeg、jq、fd、ripgrep、语言 toolchain）。什么都 brew 或什么都 apt 都不对。
### Rolling-release 发行版别装
Arch、openSUSE Tumbleweed、NixOS：你的发行版包已经够新，Homebrew 解锁不出任何东西。`brew install node@22` 跟 `pacman -S nodejs-lts` 差异不大，犯不上为这点差异装第二个包管理器。老老实实用发行版包；非要某个新版，加 PPA 即可。
### WSL 1 别用
WSL 1 跟 Homebrew bottles 有已知兼容性问题。WSL 2 没事。WSL 1 在官方文档里是 Tier 3 以下支持。如果你还在 WSL 1，先升级：`wsl –set-version
## Mac 用户跑 Linux Brew 的常见坑
1. **安装路径是 `/home/linuxbrew/.linuxbrew`，不是 `/opt/homebrew`。** 网上复制的命令 `$(/opt/homebrew/bin/brew shellenv)` 直接挂，换成 Linux 路径。
2. **没有 cask `/Applications` 这一说。** Mac 上 cask 把 `.app` 装到 `/Applications`。Linux 上没这目录。要装 GUI 应用的 cask 在 Linux 上功能很有限（有些走 AppImage / .deb）。每个 cask 在 `info.brew.sh` 看实际装什么。
3. **`brew doctor` 在 Linux 上抱怨少。** Linux 文件系统硬伤少，Homebrew 诊断更宽松。
4. **更可能需要从源码编。** Ubuntu LTS / Debian stable 的 bottle 覆盖率很好；Fedora / Arch 上经常要编——等很久。
5. **更新慢。** `brew update && brew upgrade` 在 Linux 上要几分钟，瓶颈是 formula 索引拉取和 bottle 链接解析。Mac 共享系统库所以更快。
## Linux 用户跑来用 Homebrew 的常见坑
1. **Brew 不是系统级工具。** 装完之后别 `sudo brew install`。`sudo` 只有 `curl | bash` 装那一次用。
2. **`keg_only` 跟 apt 不是一个概念。** 一些 formula 是 `keg_only`——`brew install` 完之后**不**自动 symlink 到 `~/.linuxbrew/bin/`。二进制活在 `~/.linuxbrew/Cellar/
3. **Formula 能炸掉系统。** `brew install openssl@3` 如果让它大力 link，会覆盖系统 libssl。**不要** `brew link –force openssl`。需要时分清楚 `keg_only` 模式。
4. **没有 apt-cache 同等品。** `brew info` 在，但要联网、`brew search` 也是。找东西比 apt-cache 慢。
5. **升级要手动。** `brew outdated && brew upgrade` 是 apt 自动升级的最近对应。可以 `brew autoupdate` 配 cron，但默认不会动。
## 跟 apt 老实对比
| 任务 | apt | Homebrew on Linux |
|—|—|—|
| 装 CLI 工具 | `apt install ripgrep` | `brew install ripgrep` |
| 装新版本 | 看 Debian backports / PPA / 上游源 | `brew install postgresql@17`（不需额外源） |
| 可复现（per-project） | 不太行（`apt-mark hold` 比较粗） | `Brewfile` + `brew bundle –no-upgrade` |
| 多 OS dotfiles | 没原生方案 | 同一份 `Brewfile` 给 Mac 和 Linux |
| Per-process / per-shell 工具 | 没什么 | `brew shellenv`、keg-only 覆盖 |
| 系统级服务 | apt + systemd 一流 | `brew services start`，集成度低 |
| 安全更新 | 自动（apt unattended-upgrades） | 手动 `brew upgrade`（可以 `brew autoupdate` 配 cron） |
| 性能 | 原生 | Bottles 预编译；源码 build 慢但缓存 |
| 真值来源 | 发行版上游包 | Brew 团队自己 fork 的 formulae |
| 许可证 | 发行版定 | `homebrew/core` 强制 DFSG 兼容的开源 |
## 2026 年合理的开发机模式
如果今天我要在 Debian 13 上配开发工作站：
“`bash
# apt 管 OS 层
sudo apt install build-essential git curl wget vim neovim tmux
zsh ripgrep fd-find bat jq fzf htop
network-manager-openvpn gnome-shell-pomodoro
# brew 管开发层
/bin/bash -c “$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)”
eval “$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)”
brew install python@3.13 node@22 postgresql@17 redis ffmpeg
# 一份 Brewfile 留 dotfiles 仓库里
cat > ~/dotfiles/Brewfile <
评论