适用结论 #
本次只比较 Linux。 Conky 的官方支持范围包含 FreeBSD/OpenBSD 及 macOS，Bottom 也覆盖 macOS 与 Windows，这些平台不在本次同平台对比之内，不构成任何一方的功能判断依据。
Bottom 和 Conky 在 Linux 上解决的不是同一层问题。Bottom 是一个“在终端里随时唤起、看完即走”的诊断工具：btm 启动后以 TUI 面板同时呈现 CPU 各核心折线、内存/Swap、网络 I/O、磁盘 I/O、温度与可交互的进程列表，支持鼠标点击、排序、搜索和发送信号终止进程。它的设计目标是替代 top/htop，做一次比传统命令行监控更直观的即时系统快照，用 Rust 编写，公开来源指向约 30 MB 内存、默认 1 秒刷新下 0.1—0.5% CPU 的开销量级。
Conky 是一个“常驻桌面、按你的编排持续渲染信息”的监视面板：它把 CPU、内存、磁盘、网络、进程、邮件、天气、音乐播放器等数百种数据源绘制到 X 窗口（或带条件的 Wayland）桌面上，配置文件决定显示什么、显示在哪里、以文本/进度条/图形哪种形式呈现。它的设计目标是让系统状态在不打断当前工作的情况下始终可见，而不是等你打开终端去查。
一句话：要“查一下系统现在怎么样”，Bottom 更快；要“抬头就能看见我关心的那几项指标一直摆在那里”，Conky 是唯一有意义的选项。 两者不是替代关系，可以共存，但选型时应先确认你需要的是交互式诊断还是被动常驻面板。
测试边界 #
本报告不包含自行采集的 CPU、内存或启动延迟并排实测数据。涉及资源开销的表述均标注来源类型；未实际运行验证的指标写“基于公开来源/官方文档”，不伪造跑分。
| 软件 | 版本信息来源 | 本次平台 | 验证深度 |
|---|---|---|---|
| Bottom | GitHub Releases 标注最新版 0.15.0，2026 年 11 月 1 日发布；另有 0.14.9（2026-08-27）作为近期稳定版被广泛引用。 | Linux | 基于官方文档 + 公开评测数据，未做并排资源实测 |
| Conky | 多个公开来源指向 1.25.5，2026 年 10 月 24 日；1.25.3 亦在 2026 年 10 月出现在部分发行版仓库中。 | Linux | 基于官方文档 + 公开用户报告，未做并排资源实测 |
版本号与发行版仓库中的实际可用版本可能不同步。工程部署应以目标发行版仓库或官方发布页的当前版本为准，并核验包签名。
同平台能力矩阵 #
“有 / 有限 / 未确认”表达的是在 Linux 平台上、基于可核实公开信息的判断。未确认不等于缺失，只表示公开资料不足以给出确定结论。
| 维度 | Bottom（btm） | Conky |
|---|---|---|
| 安装与兼容 | 有。官方支持 Linux x86_64、i686、aarch64；可通过发行版包管理器（apt install btm、pacman -S bottom、apk add bottom 等）、Cargo 或 GitHub Release 二进制安装。终端模拟器即运行环境，不依赖特定桌面环境。 |
有（X11 直接可用，Wayland 有条件） 。X 窗口系统下成熟稳定；Wayland 支持在 1.23+ 逐步落地，但官方措辞为“with caveats”，并非与 X11 完全等价。部分传感器/GPU 数据在 Wayland 或特定后端下可能需要额外编译选项或后端启用。 |
| 核心功能 | 有（诊断导向） 。CPU 各核心时序图、内存/Swap、网络 I/O、磁盘 I/O、温度、电池、进程列表（排序/搜索/树状视图/发送信号）。支持 --basic 切换为 htop 风格紧凑视图，降低迁移摩擦。 |
有（展示导向） 。内置对象覆盖 CPU、内存、磁盘、网络、进程、温度、电池、邮件、音乐播放器等数百种数据源，支持文本、进度条、图形控件渲染，可通过 Lua 扩展自定义绘制逻辑。进程能力有限：可以展示“top 风格”进程信息，但不提供 Bottom 那样的交互式进程终止、搜索和树状操作。 |
| 交互效率 | 有（终端内交互） 。键盘导航为主，支持鼠标点击 widget、排序、搜索、终止进程；启动后即获得一屏可操作的全景视图，不需要预先配置即可使用。 | 有限（交互本质上是配置驱动的展示） 。默认形态是被动桌面面板：你看到的是配置文件中定义好的信息，而不是一个可以按列排序、搜索进程、发送信号的交互界面。调整显示内容需要编辑配置并重载，而不是在运行界面中直接操作。 |
| 自动化 / 扩展 | 有（配置文件 + CLI 标志） 。TOML 配置文件位于 ~/.config/bottom/bottom.toml，可预设布局、主题、刷新间隔、默认 widget 组合；支持 --config 指定外部配置，便于版本化或按场景切换。无官方脚本 API；自动化以“启动时加载不同配置/CLI 参数”为主。 |
有（高度可编程，代价是复杂度） 。纯文本/Lua 配置定义完整渲染逻辑，Lua 脚本可调用外部程序、访问 HTTP、读写文件，实现 Bottom 不尝试覆盖的自定义数据源。配置迁移存在语法代际问题：旧格式向 Lua 配置转换依赖 convert.lua，公开记录显示该脚本并非无痛，可能产生需要人工修正的语法错误。 |
| 资源开销 | 有（方向性数据，非本次实测） 。公开评测指向默认 1 秒刷新下约 0.1—0.5% CPU、约 30 MB 内存；另一来源给出 0.14 版本约 10—20 MB 的内存区间。Rust 实现和 TUI 形态使其开销量级明确且可预期。 | 有限（高度依赖配置，不存在单一基线） 。Conky 的官方定位是“轻量”，但“轻量”的前提是渲染对象数量和刷新频率被合理控制。一个只显示时间、CPU 和内存的极简配置与一个每 500 ms 刷新、包含多个 graph/Lua 绘制的复杂主题，开销不在同一量级。没有可适用于所有配置的单一资源数字；部署前应按实际 conky.conf 测量。 |
| 隐私与更新策略 | 有（本地、无账号、开源可审计） 。数据来自 /proc、/sys 等本地接口，无网络上报、无账号体系的公开证据。更新通过 GitHub Releases 或发行版仓库分发。 |
有限（本地采集，但扩展可能引入外部请求） 。核心监控数据本地读取；但 Conky 配置中的 pre_exec/Lua 脚本可以发起网络请求（邮件、天气、HTTP 输出等），隐私边界由配置文件决定，而非工具本身锁定。官网未提供统一的遥测声明；开源可审计。Wayland 下部分指标的后端可用性仍在演进中，更新时需关注发行版编译选项。 |
三个真实工作流 #
工作流一：高频轻任务（临时排查“为什么卡了”） #
场景特征：正在终端或 IDE 中工作，突然感觉系统响应变慢，需要在 10—30 秒内判断是 CPU、内存、磁盘 I/O 还是某个进程出了问题。
Bottom 在这个工作流中明显更快，原因不在“功能更多”，而在“启动路径更短、交互在同一个界面内完成”。 btm 在终端中一条命令启动，默认布局把 CPU 折线、内存、网络和进程列表同时铺开；发现问题进程后直接在进程 widget 中排序、搜索、发送 SIGTERM，不需要切换到另一个终端或另一个工具。对于“现在到底怎么了”这类瞬时问题，Bottom 的交互模型是匹配的。
Conky 在这个工作流中不占优势，因为它的设计不面向“临时拉起一个可操作视图”。你桌面上常驻的 Conky 面板可以告诉你 CPU 使用率在升高，但它不提供在面板内排序进程、搜索 PID 或终止进程的能力。要继续诊断，仍然需要打开终端运行 top/btm/ps。Conky 的价值不体现在“快速排查”这个动作上。
结论反转条件：如果你的“高频轻任务”不是排查异常，而是在工作过程中持续瞥一眼固定几项指标（比如内存剩余、网络速率、磁盘温度），Conky 的常驻面板反而比“每次都要启动 btm”更符合“轻”的定义——这里的“轻”是注意力开销，不是进程开销。
工作流二：复杂任务（长期观察趋势、多指标关联） #
场景特征：需要在一段时间内持续观察多个指标的变化趋势，或者需要将系统状态与其他信息（时间、天气、邮件计数、正在播放的音乐）并置在同一视野中。
Conky 在这个工作流中有 Bottom 不可替代的位置。 Bottom 的 TUI 折线图适合秒级到分钟级的即时趋势，但它需要你在终端前主动查看；一旦关闭终端，可视化就消失。Conky 的桌面常驻面板可以在不占用终端窗口、不打断当前应用的情况下，把 CPU 历史曲线、网络流量、磁盘使用率、温度等信息持续渲染在桌面上，刷新频率和布局由你完全控制。对于“把系统健康状态作为工作环境背景的一部分”这一需求，Conky 是直接方案。
Bottom 在复杂观察中也有用，但它的强项是交互式诊断而非长时间被动展示：你可以开着 btm 让它跑，但它占用一个终端窗格，且不具备“把数据推到文件或 HTTP 端点”的 Conky 式输出路径（Conky 支持输出到 console、file 或 HTTP）。
结论反转条件：如果你需要的“复杂观察”包含对进程的操作（按内存排序找泄漏、按 CPU 排序定位异常、发送信号），Bottom 的交互能力是 Conky 不提供的；此时 Conky 只能作为“发现问题存在”的哨兵，诊断仍需回到 Bottom 或类似工具。
工作流三：异常恢复（配置损坏、桌面环境变化） #
场景特征：监控工具本身失效，或系统环境发生变化（升级桌面、切换 Wayland、更换发行版）后面板不再正常显示。
Bottom 的恢复路径更短。 它的配置文件是 TOML，结构相对扁平；即使配置损坏，用 btm --default（或删除配置文件让程序重新生成）即可回到可用状态，不依赖图形会话或合成器。终端本身的可用性就是 Bottom 的可用性底线。已知异常主要集中在数据读取层（如温度/电池需要传感器支持，部分 Linux 环境读取温度可能需要权限），而不是渲染层崩溃。
Conky 的恢复面更宽，且与桌面环境强耦合。X11 下成熟的配置在 Wayland 下可能因为合成器行为差异需要调整；own_window_type 等旧配置字段在新版本中已被 LAYERS 等机制替代，升级后旧配置可能仍能加载但行为不符合预期。配置语法从旧格式向 Lua 迁移也并非零成本——公开记录中 convert.lua 的输出存在需要人工修复的情况。此外，Conky 的常驻面板依赖桌面会话持续运行，如果合成器崩溃或桌面重启，面板可能不会自动恢复，需要额外的会话管理策略。
结论反转条件：如果异常是“Bottom 在某个新内核或新传感器上读不到温度/GPU 数据”，恢复手段是升级到已修复该硬件支持的版本（0.15.0 新增了 Linux Intel GPU 进程使用率支持，并修复了 NVIDIA GPU 被错误唤醒的问题）；这种情况下 Conky 未必有同等的即时修复，因为它的数据读取路径和版本节奏不同。
工程化选型 #
面向需要在开发机、服务器或团队标准化环境中做决策的场景，选型不应围绕“哪个图表更好看”，而应围绕运行环境约束、配置可版本化程度、维护面大小。
| 约束维度 | Bottom（btm） | Conky |
|---|---|---|
| 运行环境要求 | 低。终端可用即可，不依赖图形会话或特定桌面环境。SSH 远程会话中可完整使用，适合服务器和容器调试场景。 | 高（相对） 。需要图形会话（X11 直接可用，Wayland 有条件且仍在演进）。纯 SSH/无头服务器场景中 Conky 的常驻面板形态不适用；虽然支持输出到文件/HTTP，但那已不是“桌面监视器”的典型用法。 |
| 配置迁移与版本化 | 有（TOML 可版本化） 。bottom.toml 是结构化文本，适合放入 dotfiles 仓库；--config 允许按机器/场景切换配置。迁移到新机器只需复制文件并确保 btm 已安装。 |
有限（配置高度个性化，代际迁移有成本） 。Lua 配置和脚本是“程序”而非“设置”，迁移时可能需要适配新版本的 API 变化；旧格式向 Lua 的转换并非无损自动化。对于“一次编写、长期跨机器复制”的期望，需要接受更多的维护投入。 |
| 维护风险 | 低。功能边界清晰，版本迭代以修复兼容性和增加数据覆盖为主；单次升级引入行为回归的面较小。发行版仓库版本可能落后于上游，但 TUI 工具对旧版本的容忍度较高。 | 中到高。桌面环境演进（Wayland、合成器行为）持续影响渲染层；Lua 扩展意味着配置本身就是需要维护的代码。优点是完全开源可审计、可 pin 版本，但长期维护成本高于 Bottom，尤其当团队中只有少数人理解 Lua 配置时。 |
| 替代路径 | 如果 Bottom 因环境限制无法使用，htop/btop 是同类替代；如果需要常驻面板，则方向应转向 Conky 或桌面环境自带的小部件。 | 如果 Conky 的维护成本不可接受，桌面环境自带的系统监视器小部件（GNOME/KDE 等）可以覆盖基础常驻展示需求，但自定义程度和数据源广度通常低于 Conky。如果需要交互式诊断，Bottom/btop 是更直接的路径。 |
一个容易被忽略的工程事实：Bottom 的“低资源占用”是一个有明确量级、可预期的属性（公开数据指向 30 MB 内存量级、亚百分比 CPU），适合在资源受限或需要长期开着的环境中做基线；Conky 的“轻量”是一个条件属性——它可以很轻，但前提是配置被有意识地控制。把 Conky 当作“装上就轻”的工具来规划资源，是一个常见的判断偏差。
下载入口 #
| 软件名称 | 适用平台 | 下载地址 |
|---|---|---|
| Bottom | Windows、macOS、Linux | 去下载 |
| Conky | Linux | 去下载 |
部署前请从目标发行版的官方仓库或上游 Releases 核对包签名与版本号。Conky 在 Wayland 会话下建议先确认发行版编译时已启用 Wayland 支持，并以实际配置在目标桌面环境中验证渲染行为。