ARTICLE · 1196298
苹果电脑软件托管升级分享

dmg 手动装更保险
Mac 装软件的三条路我把 8 个应用交给了 Homebrew
dmg | cask | 一个管家
8 PARTS + CONCLUSION
👉 滑动
PART 01
Mac 上常见的三种软件安装方式
PART 02
一个常见误解:cask 是「重新打包」吗?
PART 03
三种方式核心维度对比
PART 04
为什么把 dmg 应用交给 brew 管理
PART 05
从 dmg 迁移到 brew 托管:方法论
PART 06
局限与坑
PART 07
一键复现:Brewfile
///
写在最后
THE END
App Store、dmg 手动安装、Homebrew 三者不是替代关系,而是三种定位。而 dmg 和 brew 的 cask,底层装的往往就是同一个东西——差别只在「有没有一个管家帮你记账」。
今天晚上,我干了一件早就该干、却一直懒得干的事:把这台 Mac 上 8 个「手动下载 dmg 装上去」的应用,全部交给 Homebrew 托管。
结果挺有意思——6 个顺利接管,2 个因为上游网站连不上失败了。而那 2 个失败项的 dmg 原装版本,毫发无损,照常能用。
事情很小,但它背后有个我一直想说清楚的问题:Mac 上装软件的这三条路,到底是三条互不相干的路,还是同一件事的三种做法?
我的答案可能和你想的不一样:
下面从头讲。文末有完整的迁移命令、回滚方案和这次的真实复盘,你可以直接照着做。
01
PART
Mac 上常见的三种软件安装方式
1. App Store(应用商店)
经过苹果上架审核,质量与安全性有保障;
更新统一由 App Store 管理,卸载最干净;
局限:很多开发者工具、小众应用、商业授权软件不上架;而且 App Store 版与官网版可能是两套独立构建——数据目录、自动更新机制都不同。
2. dmg / pkg 手动安装(官网下载)
最常见的「非商店」安装:浏览器下载磁盘映像(.dmg)或安装包(.pkg),双击挂载后拖拽,或者走安装向导;
优点:来源直接(官方),版本节奏完全由开发者决定,适合需要严格校验、可回滚的关键软件;
缺点:升级靠手动重下;卸载常留 ~/Library/Application Support、~/Library/Preferences 等残片;无法批量复现。
3. Homebrew(包管理器)
Homebrew 其实分两类,常被误认为「只能装命令行工具」:
brew install xxx(formula):装命令行工具、库,如 wget、git、python、node。装在 /opt/homebrew(Apple Silicon)或 /usr/local;
brew install --cask xxx(cask):装 GUI 应用,如 Chrome、VS Code、Obsidian。装到 /Applications。
02
PART
一个常见误解:cask 是「重新打包」吗?
不是。
Homebrew Cask 自己并不重新编译、也不托管软件——它的大多数方案(formula)也是去下载开发者官方的 dmg / pkg,然后帮你挂载、复制到 /Applications,并在 brew 的数据库里登记一笔。
底层装进去的 .app,往往和 dmg 手动装的是同一个东西。区别只在于「有没有一个命令行管家帮你记账、升级、卸载」。
所以「dmg 手动安装」与「brew cask 安装」不是对立关系,而是「手动图形安装」和「把安装过程自动化、并纳入包管理」的区别。
这一点我之前一直没想通,借这次机会才算是理顺了。

03
PART
三种方式核心维度对比
一张表看清区别:
| brew install --cask 应用名 | |||
| brew upgrade | |||
| brew uninstall | |||
| /Applications | /Applications | ||
注意最后一行——这张表不是「谁更好」,而是「谁适合谁」。我见过太多人一上来就问「Homebrew 是不是比 dmg 好」,这个问题本身就跑偏了。
工具错配,比没有工具更糟。
04
PART
为什么把 dmg 应用交给 brew 管理
我的理由有四条,都很实在:
一处更新:brew upgrade 全机 GUI 应用一起升,不用逐个 app 去官网看「有没有新版」;
版本可审计:brew outdated --cask 一眼看出谁落后——本质就是「人工核对版本」这件事的自动化;
卸载干净:brew uninstall --cask xxx --zap 比拖废纸篓更彻底;
可脚本化:契合 launchd、svc 这类脚本化运维习惯,新机器用 brew bundle 一键复现。
但有两个场景,我仍建议保留 dmg 手动安装:
① 需要严格校验、可回滚的关键软件。比如我本机安装有 RustDesk,对于它的升级,走的是「dmg + sha256 + codesign --verify + 备份回滚」的完整流程,全程留痕、出问题能立即还原——这种「审计可见性」比「一键升级」更重要;
② cask 没收录,或者带内核扩展、自定义安装器、需要特殊权限的应用。
说到底,手动逐个重下 dmg,是在改变结果;把应用交给包管理器托管,是在改变模式:
普通的人改变结果,优秀的人改变原因,顶级优秀的人改变模式。
05
PART
从 dmg 迁移到 brew 托管:方法论
5.1 哪些能迁?(筛选条件)
三条都满足才建议迁:
当前是 dmg 安装(非 App Store、非已经是 brew 管理);
Homebrew 有对应的 cask(brew search --casks <名称> 能反查到 token);
两者版本一致——避免迁移变成「顺带升级」,引入意外变化。
注意:App Store 安装的应用不要用 cask 覆盖。cask 装的是非 MAS 版,混用会冲突,还可能丢失 MAS 版的数据与授权。
5.2 迁移原理(为什么安全)
cask 把官方包装到 /Applications,与 dmg 装的是同一个位置;
因为版本完全一致,迁移就等于让 brew「接管」一个已存在的 app;用户数据(配置、数据库等)都在 .app 包外的 ~/Library 里,不受影响;
关键开关是 --force:/Applications/Xxx.app 已经存在,brew 默认拒绝覆盖,必须显式加 --force 才接管。
一句话:迁移动的是「管理权」,不是「数据」。
5.3 标准操作流程
# 0) 刷新方案库
brew update
# 1) 备份现有 app(版本一致时风险极低,仍建议保留回滚点)
mkdir -p /tmp/brew-migrate-backup
for a in DaisyDisk LuLu MenubarX Motrix Obsidian PopClip RustDesk Latest; do
[ -d "/Applications/$a.app" ] && cp -R "/Applications/$a.app" "/tmp/brew-migrate-backup/$a.app"
done
# 2) 关键:--force 让 brew 接管已存在的 app(逐个安装,避免单点失败阻断整批)
for c in daisydisk lulu menubarx motrix obsidian popclip rustdesk latest; do
brew install --cask "$c" --force && echo "OK: $c" || echo "FAILED: $c"
done
# 3) 校验已被 brew 接管
brew list --cask | grep -E 'daisydisk|lulu|menubarx|motrix|obsidian|popclip|rustdesk|latest'
# 4) 统一升级(后续日常用法)
brew upgrade --cask
第 2 步我特意写成 && echo "OK" || echo "FAILED" 的逐个形式——批量迁移最怕「一个失败卡住整批」,逐个报告才看得清哪些成功了、哪些要重试。
5.4 回滚方案
任一应用接管后异常,两条命令回退:brew uninstall --cask <token> 卸掉,再把 /tmp/brew-migrate-backup/<App>.app 拖回 /Applications。
⚠️ 提醒一句:/tmp 重启会自动清空,回滚要在本轮内完成。不过在版本一致的前提下,brew 装的 .app 与 dmg 装的二进制内容相同,回滚几乎用不到。
5.5 真实案例复盘(2026-10-16,本机)
目标:把 8 个 dmg 安装的 GUI 应用改为 brew 托管,要求版本一致。
结果:6 成功、2 因网络失败(原装完好)。
| daisydisk | ||||
| lulu | ||||
| menubarx | ||||
| motrix | ||||
| obsidian | ||||
| rustdesk | ||||
| latest | ||||
| popclip | pilotmoon.com |
四条关键经验:
brew 在下载阶段就中止时,不会触碰/Applications 里已存在的 app——失败的两个验证下来仍是原版本、可正常使用,零数据损失;
RustDesk 的 21118 端口监听由用户域 LaunchAgent(com.carriez.RustDesk_server)托管,独立于 .app,配置在 ~/Library;迁移后重连信息、密码都不丢,由 KeepAlive 自动拉起。但迁移必须安排在它没有活跃远程连接的时候;
LuLu 是网络过滤器(Objective-See 系统扩展),迁移后若系统提示扩展需重新授权,到「系统设置 → 网络 → 过滤器」重新启用即可;
失败项可以在网络稳定后单独重试:brew install --cask latest --force / brew install --cask popclip --force。

06
PART
局限与坑
天下没有免费的管家,这四条要提前知道:
cask 版本可能滞后于官网
开发者发新版后,要等社区更新方案和哈希,brew upgrade 才拿得到。热门应用通常几小时到一天,冷门可能数周;
与 App Store 冲突
同一个应用不要 MAS 版和 cask 版混装;
与自带自动更新冲突
部分应用(如 Chrome、VS Code)自带更新器,可能和 brew upgrade 打架,建议二选一管理;
安全
brew 会校验哈希,但第三方 tap 仍需谨慎;GUI 应用依旧受 macOS Gatekeeper 与公证检查。
至于值不值得——如果你只是偶尔装几个 App,dmg 更直观;如果你是开发者、重度用户,或者需要批量装机,Homebrew 的效率要高得多。
07
PART
一键复现:Brewfile
把当前环境导出,换机器或重装时一行恢复:
# 导出
brew bundle dump --describe --file=~/Brewfile
# 恢复
brew bundle install --file=~/Brewfile
这一条,才是 Homebrew 真正拉开差距的地方——你的软件环境,从此变成一份可以版本管理的清单文件。
///
LAST
写在最后
把这件事收一下:
App Store / dmg / Homebrew 三者定位不同
App Store 求省心安全,dmg 求来源直接可控,Homebrew 求自动化与可复现;
dmg 与 cask 底层常是同一个 .app,差异只在「有没有管家」。能用 cask 管的日常应用就交给它,需要严格留痕的关键软件保留 dmg 手工流程;
迁移 = brew install --cask <token> --force 接管已存在的 app,用户数据在包外不丢;失败项多为网络原因,且原装完好,可重试;
一次真实迁移(本机 8 个应用)印证了上面三条:6 个平滑接管,2 个因上游网络中断失败、原 dmg 装毫发无损。
我特别想说的是这 2 个失败:它们不是「迁移有风险」的证据,恰恰相反——它证明了这套流程在最坏情况下也是安全的。 下载没成功,安装就没开始,原来那份原封不动。真正危险的从来不是「新方法失败了」,而是「旧方法一直在用、却没人在管」。
回到开头那句话:三条路不是替代关系,是三种定位。想清楚你要的是省心、是可控,还是自动化,选择自然就清楚了。
我是 刘顾问,关注我,我们一起学习、共同成长。
既然看到这里了,如果觉得有用,随手点个赞、在看、转发三连吧。
THANKS FOR READING















































































