写个BrewUI的项目复盘，说点你们在GitHub README里绝对看不到的东西。
先交代一下背景。熟悉macOS开发环境的人基本都绕不开Homebrew，用命令行装个nginx、node、postgresql，一句brew install就搞定。但Homebrew有个天然的门槛——它建立在命令行之上，一切操作都需要记忆和输入指令，新人不习惯，老人也偶尔要有一次brew services list才能想起来某个服务到底有没有在跑。BrewUI就是冲着这个问题来的：给Homebrew这辆老牌赛车装一个驾驶舱，用可视化的方式管理包、服务、依赖关系和升级流程。
这个项目的定位很直接，不是替代Homebrew，而是当一个称职的“图形化控制面板”。它把终端里那些频繁使用的命令，比如brew list、brew update、brew upgrade、brew services start/stop、brew info、brew deps --tree，变成可以点击、搜索、一眼扫过就能获取信息的界面。核心价值不是炫技，而是降低使用门槛，同时把被命令行掩盖的信息结构呈现出来。
先说我做这个项目时定下的几件事：第一，必须支持brew services的完整管理，这是很多人装完Homebrew之后最常用的功能之一；第二，依赖关系必须可视化，brew deps --tree的输出在终端里看起来还行，但对于依赖一多就乱的包，图形化树状图会直观太多；第三，所有操作必须有日志回显，毕竟底层还是命令行事，你得让用户知道点击“升级”之后到底发生了什么；第四，绝不能锁死用户界面，保留终端入口。
1. 项目整体设计与拆解思路
这个项目叫BrewUI，听起来像是一个Homebrew的“皮肤”，但做起来远不止套壳这么简单。第一步要解决的，是Homebrew命令行的输出如何进行结构化解析，否则界面拿到一堆终端文本也白搭。
1.1 核心需求拆解：不只是换个窗口
我把用户场景拆成四个模块：包管理、服务管理、依赖分析与升级控制。
- 包管理：查看已安装包列表、搜索可用包、查看某个包的详细信息（版本、安装路径、依赖了什么）;
- 服务管理：查看通过
brew services管理的后台服务，支持启动、停止、重启，查看运行状态; - 依赖分析：以树状图展示某个包的依赖关系，反向查一下谁依赖了它（这个在命令行里比较麻烦，但图形界面做起来很顺手）;
- 升级控制：区分
brew update和brew upgrade，可以批量升级也可以单包升级，升级前展示依赖变更预览。
这四个模块覆盖了90%以上用户日常对Homebrew的使用频率。其余的，比如创建自己的tap、编辑formula、处理冲突，属于低频深度操作，我决定在第一版不做，保持产品廉价快捷。
1.2 方案选型：为什么不用纯前端方案
BrewUI的整体架构我必须坦白说，最初考虑过用纯Web实现，做个本地Web服务，浏览器访问，前端像Dashboard一样展示数据。这个方案上手快，UI也漂亮。但后来放弃了。
原因有三个。第一，Homebrew本身依赖/opt/homebrew目录（Apple Silicon）或/usr/local（Intel），GUI工具需要和系统路径、环境变量、shell配置文件打交道，用Web服务绕一圈再调命令行，权限和路径处理会多余很多层。第二，Web页面每次都要启动一个本地服务，关闭、重启、端口占用，这些在原生应用里面根本不存在。第三，Surface层要做菜单栏快捷入口和系统通知（升级完成后弹个通知），原生代码反而更顺手。
最终选型是Electron。我知道很多人对Electron有成见，说它体积大、内存高，但在这里它有不可替代的优势：Node.js的子进程调用非常成熟，可以直接spawn('brew', ['list'])拿输出，前端也能用现代前端框架快速迭代UI。而且Homebrew用户群体的设备性能普遍不差，几百兆内存的代价换来快速开发和多平台适配，这笔账划算。
1.3 信息架构与数据流设计
数据流是这个项目的心脏。我在设计时遵循了这样一套原则：所有界面上的数据都来自本地Homebrew命令的真实输出，做一层解析转换成结构化JSON，再由前端渲染。绝不凭空捏造包的状态，也不允许UI和实际命令行状态不一致。
每个页面的数据获取都做了缓存策略，比如列表页每30秒刷新一次，详情页在打开时拉取，升级按钮点击后强制刷新依赖树。这避免了一个常见的问题：用户明明升级了某个包，UI却还显示旧版本。所有写操作（安装、卸载、升级、服务启停）都是一个长时间运行的子进程，前端用轮询或IPC事件获取进度，完成后统一刷新。
这个过程有点像在写一个“胶水层”——把散落的命令行工具拼接成一个有逻辑的整体。难点不在于单个命令的调用，而在于状态的同步、错误处理的覆盖、各种异常输出的兼容。
2. 核心功能模块与关键实现
2.1 包列表与搜索：如何把brew list变成仪表盘
包列表是用户进入BrewUI后看到的第一个页面。命令行里执行brew list只能看到一个包名列表，没头没尾，BrewUI要呈现的信息远多于此：包名、当前版本、安装时间、占用的磁盘空间、是否有新版本可升级、被哪些包依赖。
这些信息分散在不同的命令里，需要拼合。
brew list --versions：拿到包名和版本号；brew info --json=v2 --installed：拿到详细的JSON结构，包含安装时间、依赖关系、下载统计等；brew outdated：拿到可升级的包列表；du -sh（或者读取brew --prefix下对应目录大小）：估算每个包的磁盘占用。
拼合逻辑上最麻烦的是中文包名和特殊字符包名。Homebrew允许包名包含@版本号（比如python@3.12），解析的时候如果把@当作分隔符切错，会导致后续依赖分析和升级全部错位。我踩过这个坑，后来统一用JSON输出字段做主键，而不是自己解析文本。
搜索功能的实现也值得说一下。Homebrew的brew search支持模糊匹配，但那个命令在交互模式下会有输出动画，不适合程序化调用。我改用brew search --formula和brew search --cask分开搜，每次只处理纯文本输出，再在前端本地做一次过滤，这样既保证了搜索速度，也方便同时匹配已安装和未安装的包。
2.2 依赖图与反向依赖：一眼看穿包之间的关系
依赖可视化是BrewUI最受好评的功能，也是技术上最容易翻车的地方。
Homebrew提供brew deps --tree <package>命令，能画出依赖树。但终端输出的树是文本符号拼的，格式不完全稳定，节点缩进在不同终端宽度下会变化，直接解析文本树非常脆弱。我后来改用brew info --json=v2 <package>，这个命令返回完整的依赖数组，包括dependencies、build_dependencies、recommended_dependencies、optional_dependencies。拿到数组之后，在前端用递归方式构建树结构，交给图可视化库渲染。
反向依赖更麻烦，因为Homebrew没有直接的“谁依赖了这个包”命令。我的做法是维护一个本地已安装包的依赖索引，每次进入反向依赖页面时，遍历所有已安装包的JSON数据，建立一张反向映射表：从包A出发，找到所有直接或间接依赖了A的包。这个计算量在已安装包超过500个时会有感，所以我加了异步计算和缓存，页面先渲染出已缓存的结果，后台跑完再更新。
2.3 服务管理：把brew services做成开关
brew services start|stop|restart <service>是Homebrew管理后台服务的最常用命令。它管理的服务来自/Library/LaunchDaemons（系统级）和~/Library/LaunchAgents（用户级），BrewUI把这两类分开展示，避免用户误操作系统级服务。
状态的判断不能只看进程是否存在。brew services list输出的状态列有三种：started、stopped、error。其中error状态很坑，可能是配置错误、端口冲突、权限问题，也可能是服务自己崩了。BrewUI在处理时，会把error状态的服务的最近日志片段一并展示在界面上，省得用户再到/opt/homebrew/var/log/里翻文件。
服务启停的操作我封装成了一个队列，所有动作串行执行，避免用户连续点击“启动A”和“启动B”导致两个brew services进程并发打架。Homebrew并发执行自身命令时经常出现数据库锁冲突，这一点大家使用命令行时感受不深，但GUI叠加用户快速点击场景就暴露了。实际操作中这个问题非常关键，不加锁，用户连续操作三次就会出现“Another active Homebrew process is already in progress”报错。
2.4 升级流程与日志回显：透明操作才能让人放心
升级是BrewUI操作频率最高的功能，也是最需要有“掌控感”的功能。界面拆成两段：brew update更新Homebrew自身，brew upgrade升级所有可升级的包。这里有个容易被忽略的细节，brew upgrade默认会升级所有已过期的包，用户有时候只希望升级某一个，BrewUI在界面上做了单选升级的入口，实际执行的是brew upgrade <特定包名>。
升级过程不是一个瞬间动作，尤其在大版本升级时可能耗时几分钟。我选择把子进程的stdout和stderr实时通过IPC推送到前端，在界面上模拟一个终端面板，逐行滚动显示输出。用户能看到从Downloading到Pouring再到Caveats的完整过程，每一步都有实感。一旦某个公式编译失败（比如本地缺少依赖），错误栈完整呈现在面板里，用户可以一键复制所有日志，这个功能比命令行还方便。
升级前还有一个依赖变更预览。brew outdated可以列出将要升级的包，但升级后会影响哪些依赖，默认命令不告诉你。我的做法是升级前遍历这些包的rev_dependencies（反向依赖），生成一张“影响范围”的表格，提示用户“升级node后，会影响这些已安装包”。虽然实际影响和命令行的brew upgrade逻辑一致，但把这个信息前置展示，UI的安心感提升极大。
3. 实操过程与核心环节实现
3.1 环境准备与项目搭建
开发BrewUI的机器环境是macOS 14.x + Homebrew 4.x + Node.js 20。Electron版本选了27，前端框架用React + Vite，图表库用vis-network，UI组件库用Ant Design。这个组合不算新，但胜在稳定，社区问题多，遇到坑容易搜到答案。
项目初始化用现成的electron-vite模板，一次性搞定主进程、渲染进程和预加载脚本的目录结构。关键依赖如下：
{ "dependencies": { "electron": "^27.0.0", "react": "^18.2.0", "antd": "^5.12.0", "vis-network": "^9.1.9", "dayjs": "^1.11.10" }, "devDependencies": { "vite": "^5.0.0", "electron-builder": "^24.9.1", "concurrently": "^8.2.2" } }用concurrently启动开发模式，一条命令同时拉起Vite和Electron主进程，代码热更新。这个体验太重要了，改一行React代码不需要重启整个应用。
3.2 子进程调用与数据解析
核心的包管理器调用代码，我封装了一个BrewService模块，统一负责所有和Homebrew的交互。核心思路是每次调用都返回Promise，内部分配一个唯一的任务ID，主进程通过任务ID向前端推送状态更新。
const { spawn } = require('child_process'); function runBrewCommand(args, options = {}) { return new Promise((resolve, reject) => { const brewPath = process.env.BREW_PATH || '/opt/homebrew/bin/brew'; const child = spawn(brewPath, args, { env: { ...process.env, HOMEBREW_NO_AUTO_UPDATE: '1' }, shell: false }); let stdout = ''; let stderr = ''; child.stdout.on('data', (data) => { stdout += data.toString(); if (options.onStdout) options.onStdout(data.toString()); }); child.stderr.on('data', (data) => { stderr += data.toString(); if (options.onStderr) options.onStderr(data.toString()); }); child.on('close', (code) => { if (code === 0) { resolve({ stdout, stderr }); } else { reject(new Error(`Command failed with code ${code}: ${stderr}`)); } }); }); }这里有一个关键的环境变量：HOMEBREW_NO_AUTO_UPDATE: '1'。如果不设置这个，每次执行brew install或brew upgrade，Homebrew都会先自动执行一次brew update，对于UI场景来说这会导致操作响应极慢，升级耗时翻倍。我把自动更新关掉，升级时机完全由用户决定，这也更符合GUI交互的逻辑。
JSON解析层，我写了一个parseBrewJson函数，统一处理brew info返回的数据。因为Homebrew的JSON结构在不同的Homebrew版本间偶尔会有微调，解析函数必须做容错处理，所有字段都有默认值，避免界面因为某个字段不存在直接白屏。
function parseInstalledPackages(jsonOutput) { const data = JSON.parse(jsonOutput); const packages = []; const formulae = data.formulae || []; const casks = data.casks || []; formulae.forEach((f) => { packages.push({ name: f.name, version: f.versions?.stable || 'unknown', installed: f.installed?.[0]?.version || 'unknown', dependencies: f.dependencies || [], buildDependencies: f.build_dependencies || [], recommendedDependencies: f.recommended_dependencies || [], optionalDependencies: f.optional_dependencies || [], installedOn: f.installed?.[0]?.installed_on || null, runtimeDependencies: f.installed?.[0]?.runtime_dependencies || [], size: f.installed?.[0]?.size?.poured?.out_of_bottle || null, desc: f.desc || '', homepage: f.homepage || '', outdated: f.outdated || false, caveats: f.caveats || '' }); }); casks.forEach((c) => { // cask 的处理逻辑略 }); return packages; }这些数据的字段命名我参考了brew info --json=v2 --installed的真实输出。installed_on不是所有Homebrew版本都返回，所以必须加|| null兜底，否则前端渲染时间轴会报错。
3.3 依赖树构建与渲染
依赖树构建是在渲染进程完成的。拿到某个包的依赖数组后，我需要递归查询每个依赖包自身的信息，拼接成一棵完整的树。这个过程很容易形成性能瓶颈，尤其像python这种大包，依赖可能有几十个节点。
我做了两层优化：第一，所有已经查询过的包信息缓存24小时，不重复向Homebrew发请求；第二，构建树时做成延迟加载，默认只展示两层，用户点击展开某节点时才查询更深层依赖。界面渲染用vis-network的快照模式，先计算好所有节点和边，一次性渲染。
依赖树的数据结构大概是这样的：
const treeData = { id: 'react', label: 'react', version: '18.2.0', children: [ { id: 'caco', label: 'caco', version: '1.0.1', children: [] }, { id: 'loose-envify', label: 'loose-envify', version: '1.0.0', children: [...] } ] };反向依赖图用有向图展现，节点颜色区分依赖类型：直接依赖绿色，构建依赖橙色，间接依赖灰色。这个功能在排查“为什么升级这个包会影响那么多东西”时特别好用。
3.4 服务管理面板的实现
服务管理面板核心还是调用brew services命令，但我在前端做了状态轮询和时间线记录。启动面板后，每5秒请求一次brew services list，刷新服务状态表。服务状态的数据结构：
{ name: 'nginx', status: 'started', // started / stopped / error / unknown user: 'admin', file: '/opt/homebrew/opt/nginx/homebrew.mxcl.nginx.plist', exitCode: null, lastLog: 'Worker process exited with code 0', time: '2024-11-08 14:30:22' }brew services list的默认输出是文本表格，不好解析，我又是用--json参数拿结构化数据。如果某个服务状态是error，界面会高亮显示，并提供“查看日志”按钮，点击后读取该服务的日志文件最后200行展示出来。这比用户自己去翻日志目录省事一万倍。
服务启停按钮做成了反人类的双重确认模式，尤其是对stop操作。“停止服务”按钮点击后弹出确认框，“重启服务”则直接执行。这个设计是从用户反馈中总结出来的——很多人习惯性点了停止，事后完全想不起来是自己点的。
3.5 界面交互与终端联动
BrewUI左侧边栏是四个导航：概览（Dashboard）、包管理（Packages）、依赖分析（Dependencies）、服务管理（Services）。顶部是全局搜索框，可以直接输入任意包名，搜索结果会同时展示formula和cask并标明来源。
Dashboard是用户打开应用后看到的第一个页面，信息密度很高：Homebrew版本、当前已安装包数量、可升级包数量、运行中的服务数量、磁盘占用Top10包、最近更新的包列表。这个页面是纯只读的，不给操作按钮，保持信息面板的清爽感。
终端联动功能我设了一个隐藏入口——在包详情页按一下键盘上的“`”键，会打开一个内嵌模拟终端，直接在当前包的上下文环境中执行命令。很多人问为什么要保留这个入口，其实道理很简单，GUI再全面也有覆盖不到的操作，留一条直通命令行的逃生通道，既满足了高级用户，又逼着自己在GUI覆盖面上做到尽可能广，否则用户就会觉得“开头那个终端才是真家伙，UI是摆设”。
核心操作流程上的快捷键我也做了，Command+K聚焦全局搜索，Command+1/2/3/4切换四个主页面，Command+R刷新当前页数据。这些快捷键在发布后意外受欢迎，很多用户反馈说从命令行切换过来毫无违和感。
4. 常见问题与踩坑记录
做BrewUI这段时间，踩了不少坑，有些是Homebrew本身的怪癖，有些是我自己设计上的漏洞。下面把这些记录下来，给想给Homebrew写GUI的同学一些参考。
4.1 权限问题的处理
Homebrew在Apple Silicon上默认安装在/opt/homebrew目录，这个目录对普通用户有写权限，但服务和某些编译缓存会写到系统目录。
遇到过最典型的问题：brew services start的时候，如果服务名称对应用户级LaunchAgent，需要在~/Library/LaunchAgents下有对应的plist文件，如果这个文件不存在，服务启动会失败但错误提示极不明确。BrewUI在服务管理页面的错误展示做了优化，检测到Operation not permitted时，会额外提示用户检查系统设置里的“完全磁盘访问权限”，这个权限在辅助功能配置里非常容易忽略。
还有一类问题是安装包时需要sudo权限，比如brew install某些需要写入/usr/local的旧式包。GUI应用弹sudo密码框很别扭，我最终选择不在BrewUI里内置sudo，而是检测到需要提权时弹出一条提示，让用户为当前终端进程提前授权或者直接在系统设置中给应用分配权限。避免把提权逻辑写死在应用里，这是安全底线。
4.2brew命令并发冲突
GUI应用和命令行不同，用户可能一边开着终端一边用BrewUI，两边同时执行brew install，就会触发Homebrew的并发锁机制。报错信息是“Another active Homebrew process is already in progress”，在终端里几乎遇不到，因为没人会同时开两个终端跑brew，但GUI场景下很容易。
解决方案是BrewUI在启动时检查/opt/homebrew/var/homebrew/locks下是否有锁文件，有的话弹窗提示，而不是硬等。同时在应用内部维护一个全局的任务队列，所有brew命令串行执行，队列状态在界面底部显示，用户能看到“第2/3个任务正在执行中”。
4.3 JSON字段变化导致的兼容性问题
Homebrew版本更新频率高，brew info --json的输出结构也不是一成不变。我在开发过程中经历过至少两次字段调整：一次是runtime_dependencies从数组变成小写开头的对象，一次是某些包从formulae里挪到了casks里。
对付这种问题没有一劳永逸的办法，我只能写一个“数据适配层”，定期跑一遍自己的测试用例（sample JSON和真实brew输出对比），一旦发现字段缺失，就走兜底逻辑。好在这类变更不频繁，而且Homebrew官方对JSON schema有文档背书，一般变动会在changelog里提前看到。
4.4 磁盘占用计算的坑
显示包大小是很多人喜欢的功能，但brew info --json里并不总是包含每个包的安装大小。即便有，也只是安装时的快照，升级后未必会更新。我尝试过直接扫目录算大小，但/opt/homebrew/Cellar下每个包都是实际安装内容，有些包含符号链接，直接递归统计会重复计数。
最后采用的方法是du -sk单目录计算，并忽略符号链接，同时缓存结果72小时。对于超过1GB的大包（比如node、pyenv），界面会显示“估算大小”，避免误导。
4.5 服务状态变化不实时
brew services list并不是常驻进程，你每次调用它，它都要去读plist文件、检查进程状态，所以5秒轮询已经是比较合理的频率。用户如果期望像活动监视器那样的实时数据，那就不现实了，Homebrew服务本身也没有推送机制。
这个限制在UI上的解决方案是：服务状态标签保留上一次轮询结果的时间和状态，在状态变化时短暂高亮，然后才更新。这样用户能感知到“服务刚才是启动的，现在是停止的”，而不是看到突兀的状态跳变。
5. 技术选型与工具对比
5.1 为什么不用Tauri
BrewUI发布后，被问最多的问题就是“为什么不用Tauri”。
Tauri的Rust后端确实更轻量，内存占用和包体都比Electron小很多。但我当时评估，Homebrew操作需要频繁的进程调用、环境变量管理、JSON解析，这些功能对Rust来说生态不如Node.js顺手。Node的child_process、JSON.parse和npm生态里的解析库都是一等公民，能帮我快速迭代，不必在系统库上耗费时间。
如果以后出2.0版本，我可能会考虑用Tauri重写，重点目的其实是包体积和启动速度，而不是运行内存。说句公道话，对于用户设备性能普遍不错的场景，Electron的性能短板没有想象中那么致命，开发效率才是实打实的生产力指标。
5.2 配方和Opt分支的区分
Homebrew有formula（命令行工具）和cask（图形化应用）两种包类型。brew search的结果会同时混入两者，但在UI里，如果不加区分地展示，用户很容易混淆。BrewUI在搜索结果中默认用两个Tab区分formula和cask，并且在包详情页用不同图标和配色标记类型。升版本检查时，formula用brew outdated，cask用brew outdated --cask，两个命令分开跑，避免互相干扰。
5.3 内置浏览器和外部链接
每当展示某个包的github仓库或官网时，用shell.openExternal在默认浏览器打开。这个细节很不起眼，但体验差别巨大。Electron内置的<webview>渲染外部页面会有兼容性问题，内置BrowserWindow打开外部链接又占资源，直接用系统浏览器是最稳的方案。
6. 关键决策背后的成本与收益
很多人看开源项目，只关注代码质量和功能列表，却很少去想“为什么这个项目要这么做”。我梳理了几个BrewUI最关键的决策点，把背后的成本和收益摊开来说。
先拿Electron选型举例。Electron的收益是社区巨大、人力资源好找、调试工具链完善，成本是包体积约200MB起步，内存常驻约300MB。对BrewUI的目标用户（开发人员，设备配置普遍不低）来说，这个成本可以接受，收益非常明显。如果目标用户是普通办公人群，那这个选型就是灾难。
再比如用vis-network而不是自定义SVG绘图。vis-network是一个成熟的网络图库，内置缩放、拖拽、节点高亮，开箱即用。用它的成本是bundle体积多几百KB，收益是省去了大量图交互逻辑的开发时间。我评估过，自己手写交互逻辑至少要多花两周时间，这还不算调试成本。
还有一点比较重要，从一开始我就决定BrewUI必须开源。开源带来的收益不仅是用户的信任，更重要的是社区反馈能帮你发现设计漏洞。BrewUI的服务管理面板，最初的默认排序是按服务名，后来有用户提issue说应该按启动时间排序，我一看确实更合理，改起来也不难，这类似的小改进积累了不少。
7. 后续规划与扩展方向
BrewUI第一版发布之后，我收集了不少有价值的反馈。下一步的规划有几个方向。
一个是支持多机器管理。因为Homebrew本身是单机的工具，BrewUI目前也只在本地跑。但很多开发者拥有两台以上的Mac（办公室、家里、服务器），如果能支持SSH连接到远程机器，在本地UI上管理远程机器的Homebrew包，这个场景会非常有价值，相当于把BrewUI从一个“本地GUI”变成“包管理控制台”。
另一个是升级策略的细化。目前BrewUI只支持升级全部或者升级单个包，但有些用户希望对一批特定的包做统一升级，比如所有带@版本号的运行时（python@3.11、ruby@3.2）同时升级，这需要引入“升级组”的概念，也可以保存升级预设。
还有人在issue里提到想加一个brew cleanup的定时清理功能。这个功能很有意思，因为很多用户并不了解brew cleanup --prune=all能清理掉多少旧的下载缓存和已卸载包的残留。做成一个默认每周执行的定时任务，加上清理前后磁盘空间的对比报告，可见性非常强，也容易变成留存用户的卖点。
8. 写在最后的经验与体会
BrewUI做到这个阶段，我个人最大的体会是：一个工具类项目，UI永远不只是把命令翻译成按钮，而是要重新思考信息的组织和展示方式。命令行里用户被迫用眼睛扫描文本，GUI则可以主动把关键信息前置，让用户不用想就知道下一步该点什么。
这款工具的适用人群其实比很多人想的宽。不只是开发者，那些装了Homebrew但平时只在终端里跑一两个命令的人（比如数据分析师、运维刚入门的新手、自己折腾脚本的爱好者），他们受益于BrewUI可能比老手更明显。老手可能觉得“不就是个brew Gui吗”，但对于害怕黑框的人来说，一个可视化的包管理界面本身就是安全感。
最后分享一个小技巧：如果你也想做这类“给命令行工具做GUI”的项目，最忌讳的是把界面做得太花哨。BrewUI从第一版开始，UI配色就非常有节制，主色调用的是系统蓝灰色系，所有的红色只用于错误和危险操作，绿色只用于成功状态。任何一个状态通知都做两秒自动消失的处理，既不打扰用户，又不让人错过关键信息。这种克制的设计风格，说实话比功能本身更能积累用户信任。
后续如果大家对BrewUI的实现细节感兴趣，我可以单独拆几篇博文，讲讲依赖图的可视化算法、Electron主进程与子进程的通信机制，以及如何对brew的JSON输出做高兼容解析。这几个话题任何一个单独拿出来，都能再写几千字。
