BrewUI 实战：Homebrew 安装报错与卸载残留的可视化解决指南

1. 整体设计为什么 Homebrew 需要一块“界面外衣”Homebrew 在 macOS 圈子里的地位不用多讲它几乎是开发者装环境的第一站。但用过的人都有个共同感受它不是不好用而是对非命令行重度用户太不友好。装个软件要敲brew install查依赖要敲brew tree清理垃圾要敲brew cleanup --pruneall更别提brew services那一串服务管理命令。其实每个命令都不难难的是你要记住它们还要知道什么时候该用哪个。BrewUI 的价值就落在这里。它不是要替代 Homebrew而是给 Homebrew 套了一层图形化的“操作外衣”。你可以把它理解成给命令行工具加了一个可视化仪表盘——底层调用的还是 Homebrew 那套成熟逻辑但点击按钮、勾选选项、查看状态这些操作比敲命令直观得多。从我个人经验来看BrewUI 适合三类人一是刚上手 macOS 开发、对终端天然有畏难情绪的新人二是日常用 Homebrew 但不想背命令、只想“把事办了”的效率型用户三是家里有旧 Mac、想装软件又担心搞坏系统的保守派。它把“记住命令”变成了“看懂界面”这个转换本身就有价值。再往深一层看Homebrew 的命令体系其实分成几个大的职能域软件安装与卸载、依赖树管理、更新与升级、服务进程管理、系统清理维护。BrewUI 的设计思路基本上是照这个职能域来的只是把每一个域都做成了图形化模块。这种设计的好处是你在界面里形成的操作心智回头切回终端时依然有效——你知道自己在做什么只是换了个入口而已。这点我觉得比那些把所有功能塞进一个按钮的“一键工具”高明得多因为它没有让人丧失对系统的掌控感。1.1 核心需求拆解热词背后暴露了什么我把这次相关的热搜词捋了一遍发现一个很有意思的现象除了“BrewUI”和“Homebrew”本身热度最高的几个词分别是“mac安装homebrew报错”“intel mac安装不了homebrew了”“homebrew卸载残留”。换句话说真正让用户头疼的不是“怎么用”而是“装不上”和“卸不干净”。这两个需求点其实暴露了 Homebrew 在新手场景下的两个天然痛点。第一个痛点是安装脚本对网络环境和系统路径极其敏感一遇挫折就报一长串错误初学者根本不知道从哪行开始看。第二个痛点是 Homebrew 的卸载过程涉及多个目录和系统文件删不干净会在后续重装时引发权限、路径冲突等连锁问题。这两个问题也恰恰是 BrewUI 这类图形化工具最容易体现价值的地方——它可以把安装步骤中的报错进行可视化引导把卸载后的残留清理做成可勾选的清单让用户知道每一步都在清理什么。所以这篇博文我不想只停留在“BrewUI 有多好用”的彩虹屁层面而是想连带把 Homebrew 本身的一些常见坑也讲清楚。毕竟工具再好底层逻辑还是 Homebrew理解底层才能玩得转上层。1.2 方案选型命令行与图形化的“最小干预”原则BrewUI 这类工具在架构上有一个容易被忽视的设计原则我称之为“最小干预”。什么意思就是它尽量不去改写 Homebrew 的配置、不去替换核心命令、不去注入自定义依赖而是老老实实读取 Homebrew 输出的数据再展示到界面上。也就是说BrewUI 更像是一个“只读优先”的控制台只有在用户明确点击“安装”“卸载”“升级”按钮时才把对应的brew命令传递给底层执行。这种设计有几个实际好处。第一安全性高——即使 BrewUI 本身出 bug最坏的情况也就是某条命令执行失败不会破坏 Homebrew 的安装结构。第二兼容性好——Homebrew 每次更新命令行接口BrewUI 只需要跟进解析层不用动整个逻辑框架。第三可回溯性强——用户完全知道界面上每个按钮对应的是终端里的哪条命令遇到问题去搜索引擎查也能找到对应的命令行解法。我见过一些同类工具为了“简化”过度包装反而把 Homebrew 的灵活性和可定制性阉割掉了。BrewUI 没有走那条路它保留了 command-line 的核心逻辑只是换了展示和交互的外壳。这种克制是这类工具能长期存活的关键。2. 环境准备从 Homebrew 安装到 BrewUI 部署不管是用 BrewUI 还是纯命令行前提都是先把 Homebrew 装好。所以这里我把这一章定位成“环境准备”先解决“装不上”这个最大的拦路虎再讲怎么把 BrewUI 部署起来。如果你已经装好 Homebrew可以跳过 2.1直接看 2.2 和 2.3如果是新机器建议从头看完特别是对网上那些“一键安装”脚本保持警惕。2.1 安装 Homebrew 前的关键检查项很多人一上来就执行官方安装命令报错之后才开始排查其实顺序反了。安装前花两分钟做三个检查能规避掉大部分经典报错。第一个检查是确认芯片架构。Intel Mac 和 Apple Silicon Mac 的安装路径不一样前者挂在/usr/local后者挂在/opt/homebrew。你可以在终端里执行uname -m返回x86_64就是 Intel返回arm64就是 Apple Silicon。这个信息至关重要因为后续很多报错都跟路径错位有关——比如某次升级后 brew 命令找不到了十有八九是 shell 环境变量还指向旧路径。第二个检查是确认系统目录权限。Intel Mac 上Homebrew 需要往/usr/local写入文件如果这个目录的 owner 不是你当前用户安装时就会报 Permission Denied。正确做法是执行sudo chown -R $(whoami) /usr/local把目录归属权拿回来。Apple Silicon 上一般不存在这个问题因为/opt/homebrew是全新创建的但如果你之前用 sudo 装过某些开发工具也可能留下权限残留。第三个检查是确认网络能连通 GitHub 和 Homebrew 的 CDN。官方安装脚本要从raw.githubusercontent.com拉取安装包还要从formulae.brew.sh获取软件源信息。你可以先执行curl -I https://raw.githubusercontent.com和curl -I https://formulae.brew.sh看一眼返回状态码。如果迟迟没响应说明当前网络对这两个域名连接不稳定这时候再执行官方脚本大概率会卡在下载阶段。2.2 一步步装好 HomebrewIntel 和 Apple Silicon 的差异官方推荐命令是/bin/bash -c $(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)在 Apple Silicon Mac 上如果前面的检查都通过了这条命令大概率能顺畅跑完。脚本会自动检测芯片架构然后创建/opt/homebrew目录把这个目录下的bin路径写入你的 shell 配置文件。注意新版安装脚本已经比较智能会自动识别你的 shell 是 zsh 还是 bash并写入对应配置.zprofile或.bash_profile。在 Intel Mac 上情况稍微复杂一点。如果网络没问题安装脚本也能跑通但如果你卡在 “Cloning into /usr/local/Homebrew” 这一步出不来那大概率是 GitHub 连接超时。这里我建议换用国内镜像源安装速度会稳定很多。一种做法是直接执行国内镜像站的安装脚本git clone https://gitcode.com/Homebrew/brew.git homebrew但这个方式对新手来说坑比较多——克隆完还要手动配置环境变量、还要把brew软链到/usr/local/bin。我更推荐另一种做法先下载官方安装脚本把脚本里的 GitHub 地址批量替换成镜像地址再执行。具体操作是curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh -o install.sh sed -i s|https://raw.githubusercontent.com/Homebrew/install|https://gitcode.com/Homebrew/install|g install.sh /bin/bash install.sh实测下来这个组合拳能把下载速度从几十 KB/s 拉到几 MB/s。装完之后还需要把 brew 的核心仓库和软件源都镜像化不然以后brew update还是会卡。这一步可以用两条命令解决brew install git brew tap --custom-remote homebrew/core https://gitcode.com/Homebrew/homebrew-core.git brew tap --custom-remote homebrew/cask https://gitcode.com/Homebrew/homebrew-cask.git装完之后执行brew --version确认一下如果输出了版本号说明主程序已经就位。再执行brew update brew doctor更新索引并让 brew 自检一遍。brew doctor会提示一些潜在问题比如“你还在用旧路径”“某个目录权限不对”这时候按提示一条条修就行。我自己踩过的坑是忽略了一个 Warning结果后面装 nginx 的时候目录冲突来回折腾了半小时。所以别嫌麻烦这步值得做。2.3 BrewUI 的首次启动与界面结构Homebrew 装好后BrewUI 的安装就简单了。它本身就是一个 Homebrew formula所以一条命令就能装brew install brewui如果你的 Homebrew 用的是默认官方源而发现 install 时找不到这个包需要先brew update刷新一遍 formula 索引。装完之后在终端输入brewui就能启动。第一次启动时BrewUI 会做一次环境自检检查 Homebrew 安装路径、当前用户权限、shell 配置里的 PATH 是否包含 brew 的可执行目录。这一步如果卡住基本都是前面 2.1 里提到的路径或权限问题回到那一步排查就好。透过界面结构你能很清楚地感知到 BrewUI 对 Homebrew 命令体系的映射逻辑。主界面通常分成几个区Dashboard 显示总览——已安装的 formula 数量、cask 数量、磁盘占用、可升级项目Packages 区是包管理主战场——可以浏览已装包、搜索远程包、勾选安装或卸载Services 区管理后台服务——启动、停止、重启甚至设置开机自启Tools 区收纳了清理临时文件、检查系统依赖、对比 update 版本等实用功能。我用了一圈下来最大的感受是每个区域都对应着一类终端操作场景但交互方式完全图形化鼠标点选即可不用记参数。3. 核心功能拆解从“看懂”到“会用”工具装好了接下来要解决的是“怎么用好”。BrewUI 的界面虽然直观但如果你不理解 Homebrew 自身的几个核心概念很多操作还是容易做错。这一节我会先讲两个绕不开的概念——formula 和 cask再结合 BrewUI 的实际界面讲日常最常用的几个功能模块。学到这章结束你应该能独立完成一次“搜索-安装-配置-更新-清理”的完整流程。3.1 理解 formula 与 cask包的两副面孔接触 Homebrew 的人最先会遇到且最容易混淆的两个词就是 formula 和 cask。简单来说formula 是“命令行软件包”定义了一个软件的下载地址、依赖项、编译参数和安装步骤。你安装wget、nginx、python3.11时走的就是 formula 这条链路。cask 是“原生图形应用包”用来分发带.app后缀的 macOS 应用比如 Chrome、Visual Studio Code、微信这类。它会把应用下载到统一目录然后软链到/Applications或你指定的应用目录。这两个概念的差异直接决定了你后续的操作选择。想装开发工具链就去 formula 仓库找想装日常办公软件就去 cask 仓库找。你还可以用一句话概括公式是“让命令行能跑起来的程序”cask 是“让图标出现在启动台的应用”。在 BrewUI 里两者会被明显分开比如 Packges 区域会有多个 Tab 或筛选器用来区分“Formula”和“Cask”。搞清楚自己要找的是哪一类搜索效率能翻一倍。有个小细节值得注意同一个软件可能同时存在于 formula 和 cask比如nginx在 formula 里有但它的官网也提供.dmg安装包。在这种情况下优先选 formula 版本因为 Homebrew 能帮你管理依赖和版本如果你只想“下个软件装好不折腾”那 cask 更省事。3.2 用 BrewUI 搜索、安装与更新软件包在 BrewUI 的 package 搜索栏输入关键词它会把公式库和 cask 库里的匹配项都列出来并且标注类型、版本号、安装状态。这一步本质上等于执行了brew search但展示结果更友好——你直接能看到这个包是干嘛的而不是只看到一个名字列表。选好包之后点击 Install 按钮。如果你点开的包带有很多依赖项BrewUI 会弹出一个依赖确认窗口挨个列出依赖的名字和版本让你勾选确认。这对应到命令行的实际操作就是brew install会先解析并安装依赖最后再装目标包。我建议新手把依赖列表仔细看一眼不要盲点确认。有一次我想装一个图像处理库依赖里带了一个旧版 OpenSSL我没注意就装了结果和系统里已有的新版 OpenSSL 发生了符号冲突。如果当时在 BrewUI 里多花几秒检查一下完全可以避开这个坑。更新包的逻辑也值得讲一下。BrewUI 的 Dashboard 会显示“有 X 个可升级包”点击升级按钮它会按依赖顺序逐个执行brew upgrade。但我不建议一有更新就跑“升级全部”尤其是某些系统级依赖比如python、node、openssl更新可能导致其他软件环境变量路径失效。更稳妥的做法是在 BrewUI 的升级列表里单选某个包单独升级升级完跑一下brew doctor确认无重大问题再继续下一个。虽然多花几分钟但能省掉后面好几个小时的排障时间。3.3 服务管理与日志查看brew services 的可视化替代Homebrew 的brew services命令是管理后台服务的最佳工具比如让 MySQL、PostgreSQL、Redis 随开机自启、监听端口、跑在后台等。命令行下的用法不复杂但新手经常搞不清楚 “run” 和 “start” 的区别——run是前台临时跑关掉终端服务就停start是注册成后台服务会开机自启。这个区别在 BrewUI 里呈现得非常直白。在 Services 区域你会看到一个服务列表每个服务有当前状态、启动方式、端口信息。点击一个服务可以 Stop、Start、Restart还能设置 Launch Agent 的自启策略。这里我要重点提醒给服务设置自启之前先想清楚自己是不是真的需要它常驻。我见过有人把 Redis 设成开机自启结果电脑每次开机内存就被占用 500MB还找不到原因。如果你只开发时用某个服务把它设为手动启动用的时候再打开更合理。日志查看功能也值得一提。命令行下要看服务日志你得执行tail -f /usr/local/var/log/nginx/error.log这类命令再盯着终端输出。BrewUI 把日志集成成了可视化面板能按时间筛选、按级别过滤、搜索关键词。虽然它本质上还是读取同一份日志文件但省去了记忆日志路径的负担。对于刚接触服务管理的用户这个面板能帮他们更快理解“服务到底在做什么”。3.4 清理与维护别小看 cleanup 和 doctor 的联动用 Homebrew 一段时间之后系统里会积累不少“过期缓存”。比如你升级了某个包旧版本的压缩包还留在缓存目录再比如某次安装中断缓存目录里留下了一批残缺下载文件。这些文件加起来能占好几个 GB。命令行下清理缓存是brew cleanupBrewUI 在 Tools 区把这件事做成了“一键清理”按钮还能显示预计释放的空间大小。但我的真实建议是清理之前先跑一次brew doctor检查整体健康度。BrewUI 里对应的就是“健康检查”或“诊断”功能。brew doctor会检查系统目录是否有多余文件、链接是否失效、环境变量是否有冲突并给出建议。如果你系统里有问题直接清理缓存可能解决不了根本矛盾反而会把排障线索一起清掉。正确顺序是先诊断再清理最后更新。还有一类“残留”不在 Homebrew 的管理范围但 BrewUI 的清理功能会帮你识别——比如.DS_Store文件、崩渍日志、临时编译产物。这些不会影响 brew 本身但堆积多了会影响磁盘空间和某些工具的扫描速度。BrewUI 会列出一个“可清理项”清单你勾选完再执行比在终端里一点点找要省心得多。4. 典型问题排障安装、卸载与残留清理实录这一章是全文的重头戏对应的是热搜词里最密集的需求安装报错、Intel Mac 装不了、卸载残留。我把这些场景拆成几个典型场景先讲现象再讲排查思路最后给出解决命令。这些问题不只在 BrewUI 里会遇到纯命令行操作同样适用只是 BrewUI 会把部分排查过程可视化。4.1 “curl 连接失败”与科学排查安装报错最高频的安装报错长这样curl: (7) Failed to connect to raw.githubusercontent.com port 443: Connection refused看到Connection refused别慌这不一定是你操作错了通常是网络出口到 GitHub 的连接不稳定。我建议按照从近到远的顺序排查。先测当前机器的网络基础连通性比如浏览器能不能打开常规网站再测到 GitHub 域名的连通性执行ping raw.githubusercontent.com或curl -I https://raw.githubusercontent.com。如果确实连不上就用 2.2 里提到的镜像源方案安装不要反复重试官方脚本——同一网络环境重试十次结果大概率还是一样的。还有一类报错是执行脚本后发现brew: command not found。这种情况基本可以断定 Homebrew 装了但 shell 环境变量没配置对。Apple Silicon 对应的路径是/opt/homebrew/binIntel 对应/usr/local/bin。你可以执行eval $(/opt/homebrew/bin/brew shellenv)按自己芯片选路径临时把 brew 拉进当前终端然后再把这段代码写入.zprofile让它登录终端时自动加载。在 BrewUI 里对应的是设置向导里的“修复 PATH”按钮点击后它会自动帮你补全配置。注意不要用sudo执行 brew 的安装或升级命令。Homebrew 的设计原则就是不用 root 权限管理软件。如果某个操作提示需要 sudo说明路径权限可能被改坏了去检查/usr/local或/opt/homebrew的 owner比硬提权合理得多。4.2 Intel Mac 安装困境不是不能装是方法没选对“Intel Mac 安装不了 Homebrew 了”这个热搜词我猜很多人遇到的是两类情况。第一类是系统版本太旧比如 macOS Catalina 以下新版 Homebrew 已经不提供官方支持。这种情况正确思路是找一个与系统版本兼容的旧版安装脚本不要硬上最新版。第二类是/usr/local目录权限被污染导致安装脚本无法完成创建目录的操作。一个非常实用的排查记录是在 Intel Mac 上安装卡住时先看/usr/local是否存在。如果存在执行ls -ld /usr/local查看 owner。如果 owner 是root你需要sudo chown -R $(whoami) /usr/local如果目录不存在直接创建并赋权。然后重新执行安装脚本。这个操作可以把一大半的 Intel 安装报错直接解决掉。另外有一点值得说Intel Mac 跑 Homebrew 时部分 formula 会被标记为“已弃用”或需要额外编译参数。如果你执意要装一个官方只支持 arm64 的包BrewUI 会给出提示告诉你该版本可能在 Intel 架构上有兼容风险。我的建议是别绕过警告硬装换一个功能相似但支持 x86_64 的替代品省心得多。4.3 卸载残留的根源Homebrew 到底写了哪些文件“homebrew 卸载残留”这个热搜词背后本质上是用户搞不清楚 Homebrew 在系统里都动了哪些地方。Homebrew 本身有一套官方卸载脚本/bin/bash -c $(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/uninstall.sh)它会把安装目录、缓存目录、日志目录、服务配置等核心路径清理掉。但实测下来它并不会帮你删干净所有东西。残留最集中的几个地方分别是/usr/local或/opt/homebrew下没被脚本扫到的自定义安装目录~/Library/Caches/Homebrew的下载缓存~/Library/Logs/Homebrew的老日志以及~/Library/LaunchAgents和/Library/LaunchDaemons里由brew services注册的自启项。如果你确定要彻底卸载 Homebrew我会推荐一个分层策略第一步在 BrewUI 的 Services 区把用 Homebrew 启动的服务全部停止并取消自启第二步用官方卸载脚本卸载主程序第三步手动清理 2.2 之前记录的缓存目录和日志目录第四步编辑.zprofile和.bash_profile删掉所有 brew 路径相关行。这四步做完才算真正“干净”。我特别强调一个新手容易忽略的细节卸载之前先备份一份已安装包清单。执行brew list --formula和brew list --cask把输出保存到本地文件。万一后续你想回到 Homebrew这份清单能帮你一键恢复所有软件不用一个个回想自己装过什么。BrewUI 里对应的是“导出包列表”功能你也可以直接用它。4.4 常见报错与解决方案速查表这里我把平时遇到频率最高的几类问题整理成一张速查表方便大家直接对照。报错或现象根本原因推荐处理curl: (7) Connection refused到 GitHub 域名连接不稳定使用镜像源安装或 clonebrew: command not foundshell PATH 未包含 brew 路径写入.zprofile或点 BrewUI 修复 PATHError: Permission denied安装目录 owner 不是当前用户sudo chown -R $(whoami) /usr/local或/opt/homebrewError: The following formulae are disabled包已归档或不再支持当前架构换用替代包不要绕过警告Error: Cannot install under RosettaIntel 环境跑 arm64 包确认芯片架构选择 x86_64 版本brew update长时间卡住Homebrew 仓库拉取超时将 homebrew-core 与 homebrew-cask 镜像化卸载后重装出现冲突缓存目录或服务配置残留按 4.3 的四步分层清理策略执行Your system is not ready to installRuby 版本或 Git 版本过旧先升级系统自带的 Command Line Tools这张表不是为了让你一条条背而是作为排障入口——遇到现象先去定位“根本原因”这一列原因清楚了解决方案自然就浮现了。5. 一次完整实操记录用 BrewUI 从零安装 Nginx前面章节讲了不少原理和理论这一章我用一个实际案例串起来在一台相对干净的 macOS 上通过 BrewUI 和命令行配合把 Nginx 从安装到启动服务完整走一遍。这个过程基本涵盖了日常使用 Homebrew 的所有关键操作也能让读者直观看到图形化界面和命令行到底怎么协作。5.1 实操前环境核对我用的是一台 Intel MacBook Pro系统是 macOS Ventura芯片架构x86_64。安装前先做了三个确认uname -m返回x86_64git --version确认 Command Line Tools 已装curl -I https://raw.githubusercontent.com能返回 200。所有检查通过后我直接执行了官方安装脚本。如果网络卡顿严重大家就按 2.2 的方式换成镜像源步骤不变。安装结束后我把 brew 路径写进了 shell 配置执行brew --version看到版本号。接着执行brew update刷新索引再执行brew doctor系统提示 “Your system is ready to brew”——到这里冷启动阶段才算彻底结束。5.2 用 BrewUI 安装 Nginx 并启动服务在 BrewUI 界面搜索nginx结果列表里能看到 formula 版本和 cask 版本这里 cask 其实不是官方发布的就是提醒大家区分。我直接选择 formula 版本点击 Install。BrewUI 弹出依赖树Nginx 的依赖不算多一般会列出pcre2、openssl3等几个我确认没问题点击确认。等安装进度走完界面会显示 “Installed”。此时我在终端执行which nginx确认路径已经在/usr/local/bin/nginx下。然后是启动服务环节。在 BrewUI 的 Services 区勾选 Nginx 自启点击 Start它会调用brew services start nginx。接着我打开浏览器访问http://localhost:8080看到 “Welcome to nginx!” 的页面整个流程就算通了。5.3 关键配置文件的定位与修改思路Nginx 安装成功后最好的学习方式是去改它的配置文件看看各种参数怎么生效。在 Homebrew 环境下Nginx 的主配置默认在/usr/local/etc/nginx/nginx.conf如果你改过安装前缀路径会相应变化。使用 BrewUI 或者命令行安装的包配置文件都不会在应用的安装目录里而是在独立的 etc 目录下这点很多人都不知道。想要修改端口在http块里找到listen指令默认是8080Homebrew 为了避开 80 端口权限默认用的非特权端口把它改成8081保存后重启服务刷新页面就能看到新端口生效。这个过程之所以值得亲自动手一遍是因为你能直观感受到“配置—重启—验证”的工作闭环。之后你在命令行里遇到类似 Web 服务的管理也大概率是这个思路。补充一个修改配置的小技巧改 nginx.conf 之前先执行nginx -t做语法测试有错误会直接输出到终端。这个习惯能避免你改了配置文件一重启服务直接挂掉的尴尬。BrewUI 的服务面板里每次重启前也会做一次初步检查但底层逻辑还是靠nginx -t。6. 使用心得与几点建议BrewUI 用了一段时间我对它的定位越来越清晰它不是一个“替代终端”的工具而是一块“翻译层”把 Homebrew 的命令行逻辑翻译成图形界面让你在做操作时能更直观地理解每一步的意图。它适合作为初学者的脚手架、日常维护的加速器但如果你已经是个每天要和几十个包打交道的老手你应该还是会回到终端因为你需要管道、需要脚本、需要精细参数控制这些图形化工具很难完整覆盖。有几个小建议可以分享给正在上手的朋友。第一不要把 BrewUI 当作“兜底工具”——界面上任何操作你都要知道对应的命令是什么遇到问题才有排查思路。第二定期导出一份包清单备份到网盘或 Git 仓库系统重装时这玩意儿比任何配置都值钱。第三保持 Homebrew 本身的健康度BrewUI 只是界面底层还是 Homebrew 那一套体系brew doctor依然值得定期跑一跑。最后说一个我自己的实际操作习惯我通常用 BrewUI 做安装、卸载、清理这类的“管理型操作”用终端做编译、定制、调试这类的“开发型操作”。两条线并行互不干扰效率也最高。目测 BrewUI 后续还会在服务日志可视化和依赖关系图谱上继续增强如果能把这两块打磨得更细它会在“让 Homebrew 更好用”这个方向上走得更远。