OpenTUI 是 Ink 的真正替代品吗？

对于需要持续重绘的终端 UI（例如流式输出的 agent、日志查看器和实时仪表盘），OpenTUI 是 Ink 的真正替代品；但它对运行时的前沿要求以及 0.x 版本的频繁变动，使得 Ink 仍然是面向普通 Node 用户发布 CLI 时更安全的默认选择。

如果你曾经看着自己的 Ink 仪表盘在繁忙的日志流下卡顿，你大概已经明白为什么人们开始四处寻找替代方案。而 OpenTUI 正是为填补这一空白而生。

接下来的内容将用同一套标准衡量这两个库：Ink 的渲染器上限在哪里、OpenTUI 的架构改变了什么、同一个小型 UI 在两者中分别是什么样子、OpenTUI 在生产环境中赢得了多少信誉，以及切换在运行时、生态和稳定性方面的代价。文末会给出建议。

Ink 的渲染器上限在哪里？

Ink 的天花板是它的渲染节流：默认情况下它将重绘限制在每秒 30 帧，超出该预算的每一次状态更新都要等待下一帧。关于 Ink 的基础知识，可参见此前那篇使用 Node.js 构建终端界面的指南，它在 2025 年 12 月推荐了 Ink，那时 OpenTUI 还不是一个严肃的选项；本文正是对那一结论的更新。

这个节流是有文档记录的，不是道听途说。Ink 在历史上曾在其渲染函数外围硬编码了 32 毫秒的节流，这正是被广泛转述的“32 FPS 上限”一说的来源：32 是以毫秒为单位的间隔，由此得出的帧率其实是每秒 30 帧的上限。当前的 Ink 将其暴露为 maxFps 渲染选项，默认值为 30，并提供 incrementalRendering 选项，把每次重绘限制在发生变化的行上。所以上限是可调的。不可调的是架构：每一帧都在 JavaScript 中合成、以字符串方式做 diff，并由运行你应用逻辑的同一个事件循环写入 stdout。

对于一个 spinner、一个表单或一个进度条，这一切都不会被察觉。当输出开始流式涌入时，它才会显现出来：模型 token 到达速度快于帧预算、日志查看器追踪一个繁忙的服务、仪表盘重绘大片区域。此外还有内存下限。一个 Ink 进程为了可能只有几行输出，就要背负 Node 运行时加上 React 的 reconciler；目前没有可靠的公开测量数据来量化这份开销，所以对你读到的任何具体 MB 数字都应持怀疑态度。

OpenTUI 增加了什么？

OpenTUI 把渲染完全移出了 JavaScript。它的核心用 Zig 编写，原生处理屏幕缓冲区、绘制和输入解析；TypeScript 通过 FFI 与之通信，在 Bun 上使用 bun:ffi，在 Node 上使用其实验性 FFI。布局仍然是熟悉的那一套：尺寸和定位通过基于 Yoga 的 flexbox 运行，与 Ink 使用的是同一个引擎，因此 flexDirection、flexGrow 等属性可以直接迁移。

除渲染器之外，还有两点值得关注。首先，内置组件覆盖了 Ink 交给第三方包去做的领域：可获取焦点的 Input 与 Textarea、Select、ScrollBox、Code 中由 tree-sitter 支持的语法高亮、Diff 视图，以及 Markdown。另外两个——文本表格和内嵌终端——仅以 Core renderable 的形式存在，因此 React 和 Solid 无法以 JSX 元素的方式使用它们。其次是框架选择：@opentui/react 和 @opentui/solid 都是一等公民绑定，因此偏好用细粒度响应式来处理高频更新的团队不必被锁定在 React 的 reconciler 上。此外还有一个 Three.js WebGPU 集成，对本文的比较而言只是个趣闻，而且仅支持 Bun。

同一个 UI 在 Ink 和 OpenTUI 中分别是什么样子？

要看清迁移成本，最简单的办法是把同一个 UI 写两遍：一个带边框的面板、一行文本、一个按键切换状态，以及干净的退出。以下代码片段针对 Ink 7 和 OpenTUI 0.5.x。

Ink，使用 npx create-ink-app 脚手架创建：

import React, { useState } from "react";
import { render, Box, Text, useApp, useInput } from "ink";

function App() {
  const [name, setName] = useState("world");
  const { exit } = useApp();

  useInput((input, key) => {
    if (key.escape) exit();
    if (input === "r") {
      setName((prev) => (prev === "world" ? "terminal" : "world"));
    }
  });

  return (
    <Box borderStyle="round" padding={1} flexDirection="column">
      <Text>Hello, {name}! Press r to toggle, Esc to quit.</Text>
    </Box>
  );
}

render(<App />);

OpenTUI，使用 bun create tui --template react 脚手架创建：

import { useState } from "react";
import { createCliRenderer } from "@opentui/core";
import { createRoot, useKeyboard, useRenderer } from "@opentui/react";

function App() {
  const [name, setName] = useState("world");
  const renderer = useRenderer();

  useKeyboard((key) => {
    if (key.name === "escape") renderer.destroy();
    if (key.name === "r") {
      setName((prev) => (prev === "world" ? "terminal" : "world"));
    }
  });

  return (
    <box style={{ border: true, padding: 1, flexDirection: "column" }}>
      <text>Hello, {name}! Press r to toggle, Esc to quit.</text>
    </box>
  );
}

const renderer = await createCliRenderer();
createRoot(renderer).render(<App />);

这份 diff 本身就是迁移指南。入口点从 Ink 的 render() 调用变成了 @opentui/core 的 createCliRenderer() 加上 @opentui/react 的 createRoot(renderer).render()。首字母大写的 Box 和 Text 组件变成小写的 box 和 text 内置元素，且多个单词组成的元素名要用连字符连接，例如 <ascii-font>。Ink 的 useInput 和 useApp 对应 OpenTUI 的 useKeyboard 和 renderer.destroy()。React 本身则完全照旧：ink 和 @opentui/react 都要求 React 19.2 或更高版本，useState 的用法完全一致。焦点模型的差异更大：Ink 提供内置 Tab 循环的 useFocus，而 OpenTUI 则通过一个由你在 state 中管理的 focused prop 来赋予焦点。

信誉：OpenTUI 在生产环境中渲染 OpenCode

OpenTUI 不是一个演示项目。它由 OpenCode 背后的公司 Anomaly 打造，项目 README 称 OpenCode 是其生产部署案例，服务数百万人。那种工作负载——一个编码 agent 将模型输出、diff 和语法高亮的代码流式送入交互式终端——恰恰是 Ink 的节流会显形的场景。它的技术血统也很重要：OpenCode 的界面是从 Go 与 Bubble Tea 重写迁移到 OpenTUI 上的。对 React 用户有一点需要注意：OpenCode 的 TUI 运行在 Solid reconciler 上，因此生产环境的实战检验更多覆盖的是 Core 和 Solid 绑定，而不是 @opentui/react——与 Core 和 Solid 不同，后者在 CI 中并没有 Node.js 的测试通道。

代价：版本变动、运行时与生态

代价集中在三个方面，其中运行时问题是一个分发问题，而非开发体验问题。

Ink CLI 可以在任何运行 Node 22 或更高版本的地方运行。而 OpenTUI CLI 会把一项前沿要求压到每一位终端用户身上：根据运行时支持矩阵，这意味着 Bun 1.3.0+ 或 Node.js 26.4.0+ 并带上实验性 FFI 标志，仅支持 ESM，用 CommonJS 的 require 会直接失败。对于一个发布到 npm、由陌生人安装的工具来说，这要么会缩小你的受众，要么会把你推向编译成二进制文件的分发方式。

稳定性是第二项代价。releases 页面显示 v0.4.4 到 v0.5.8 在大约六周内相继发布。在 0.x 线上，这种节奏意味着你需要锁定版本并密切关注 changelog。相比之下，Ink 的 API 多年来跨越多个大版本始终保持稳定。第三是生态：Ink 的社区包、实践方案和 Stack Overflow 回答目前在 OpenTUI 这边还没有对等物，不过 OpenTUI 更丰富的内置组件在一定程度上弥补了这个差距。调试能力大致持平；两者都通过 DEV=true 支持 React DevTools，而 OpenTUI 还额外提供了控制台叠加层和渲染诊断。

你应该从 Ink 切换到 OpenTUI 吗？

如果你的 TUI 需要持续重绘，且运行时由你掌控，那就现在切换：内部 agent 前端、给自己团队用的日志查看器，或者任何以编译后二进制文件分发、从而让 Bun 依赖消融在构建过程中的场景。在这些场景中，Zig 核心、Code 与 Diff 组件以及 Solid 选项都是实打实的优势，而 OpenCode 也证明了这套架构在规模上的可行性。

如果你要向 npm 发布面向普通 Node 用户的 CLI，如果你的 UI 主要是表单、提示和进度条而非持续的流式输出，或者如果你无法承受次版本之间的破坏性变更，那就继续留在 Ink。Ink 默认的 30 fps 可通过 maxFps 调整，而它的生产用户名单——其中包括 Claude Code、Gemini CLI、GitHub Copilot CLI、Wrangler 和 Prisma——说明了这种节流模型能走多远。对于愿意离开 TypeScript 的团队，Bubble Tea 和 Ratatui 仍是选项，但那已经背离了本文的前提。

结语

OpenTUI 凭借其架构和生产环境证据，赢得了“真正替代品”的称号，而 Ink 则凭借稳定性和覆盖面守住了默认选项的位置。决定性的问题不是哪个渲染器更快，而是你的用户能否运行你的运行时。用 bun create tui --template react 为你最吃性能的界面做个原型，放到真实的数据流下观察，然后让运行时约束——而不是基准测试——来做决定。

常见问题

OpenTUI 只支持 Bun，还是也能在 Node.js 上运行？

不，OpenTUI 并非只支持 Bun。Bun 1.3.0 及以上可用，Node.js 26.4.0 及以上同样可用，前提是你的应用是 ESM，并且启动 Node 时带上实验性 FFI 标志；如果通过 CommonJS require 引入 Core，它会抛出错误。仍有少数部分只支持 Bun，其中包括 @opentui/three 和运行时加载的插件，而 Node 的 FFI 支持本身也是实验性的，因此 Bun 依然是经过更充分测试的路径。

OpenTUI 支持 Windows 吗？

支持。预构建的原生核心包提供 Windows x64 和 Windows arm64 版本，同时也提供 macOS 以及 Linux 的 glibc 和 musl 构建。在 Windows 上，项目自身的测试是通过 x64 上的 Bun 进行的，而其 Node.js 验收通道运行在 Linux x64 上，因此在发布前请先在真实的 Windows 终端里试用一个 Windows 版本，尤其是当你的用户使用 Node 而非 Bun 时。

OpenTUI 支持 React DevTools 吗？

支持，尽管网上流传着相反的说法。@opentui/react 的文档说明了如何将 react-devtools-core@7 安装为开发依赖、运行 npx react-devtools@7，并用 DEV=true 启动应用以检查组件树。Ink 同样通过 DEV=true 支持 React DevTools，因此调试工具并不是这两个库之间有意义的差异点。

我应该使用 OpenTUI 的 React 绑定还是 Solid 绑定？

若想走经过最充分生产验证的路径，请选择 Solid：OpenCode 的终端界面运行在 Solid reconciler 上，而 @opentui/solid 拥有 @opentui/react 所缺少的 Node.js CI 覆盖。如果你的团队本来就在用 React，那就选 React；该绑定要求 React 19.2.0 或更高版本，并提供 useKeyboard 和 useTimeline 等 hook。注意 @opentui/solid 将 Solid 精确锁定在 1.9.12 版本。