Tutu：C#跨平台终端操控库的设计原理与TUI应用实战-平芜编程栈

1. 项目概述：为什么我们需要一个跨平台的终端操控库？

如果你用C#写过命令行工具，或者想给控制台程序加点颜色、动动光标，大概率会先想到Console类。Console.SetCursorPosition,Console.ForegroundColor，用起来似乎挺简单。但当你尝试写一个更复杂的交互式应用，比如一个带进度条、支持鼠标点击、能响应终端大小变化的TUI（文本用户界面）时，很快就会撞上南墙。

第一个问题是平台兼容性。在Windows上，Console类背后是Win32 Console API；在Linux或macOS上，它依赖的是POSIX终端和ANSI转义序列。这两套机制天差地别。Console.MoveBufferArea这种方法在非Windows系统上直接抛PlatformNotSupportedException。你想用ANSI颜色码？在Windows 10之前的版本里，默认是关闭的，得先调用一个Console的方法来启用，而且行为还不完全一致。

第二个问题是功能缺失和粗糙。原生的Console类对鼠标事件的支持几乎为零，想隐藏光标？没有直接方法。想进入“原始模式”（Raw Mode）让按键输入不经缓冲直接读取？在 .NET 里你得自己调用平台原生API，写一堆#if条件编译代码，维护起来头大。

这就是Tutu要解决的问题。它是一个用纯C#编写的终端操控库，目标是把所有平台（Windows 7及以上、所有主流Unix-like系统）的终端操作，抽象成一套统一、线程安全、易于使用的API。它的灵感来源于Rust生态里大名鼎鼎的crossterm，但完全为 .NET 开发者量身打造。无论你是想给日志输出着色，还是构建一个像htop或ncdu那样的全屏终端应用，Tutu都试图成为你工具箱里那把趁手的瑞士军刀。

2. 核心设计思路与架构解析

2.1 统一抽象层：如何屏蔽平台差异？

Tutu最核心的设计是在底层构建了一个统一的抽象层。它没有试图用一套魔法代码在所有平台上实现所有功能，而是承认差异，并优雅地封装它们。

其架构大致分为三层：

平台检测层：在运行时，Tutu会首先检测当前运行的操作系统（通过RuntimeInformation.IsOSPlatform）和终端类型（例如是经典的Windows控制台，还是Windows Terminal，或是基于Unix的终端如xterm、kitty等）。这一步决定了后续将使用哪一套后端实现。
后端实现层：这是库的引擎室。
- Windows后端：对于Windows，它主要利用kernel32.dll中的Console API（如SetConsoleCursorPosition,SetConsoleTextAttribute）来实现光标移动、颜色设置等。对于更高级的特性（如256色、RGB色），在Windows 10及以上版本中，它会混合使用Console API和输出ANSI转义序列（因为现代Windows终端已支持ANSI）。
- Unix后端：对于Linux、macOS等系统，它完全基于ANSI/VT转义序列。这些是由终端模拟器（如xterm, gnome-terminal, iTerm2）解析的一系列标准控制字符序列，例如\x1b[31m表示红色前景色。Tutu负责生成正确的序列并写入标准输出。
统一API层：这是开发者直接接触的部分。无论底层是Win32 API还是ANSI序列，Tutu都提供如Cursor.MoveTo(x, y),Style.SetForegroundColor(Color.Red)这样的方法。库内部处理了所有脏活，比如在Windows上，MoveTo可能会调用SetConsoleCursorPosition，而在Unix上，则是向stdout写入\x1b[{y};{x}H。

这种设计的最大好处是开发者无需关心“我在哪里运行”。你可以专注于业务逻辑，用同一套代码写出能在任何地方表现一致的控制台应用。

2.2 命令式执行模式：更符合直觉的流程控制

Tutu引入了一个非常巧妙的概念：命令（Command）。几乎所有终端操作都被建模为一个实现了ICommand接口的对象。例如，移动光标、设置颜色、打印文本，都是命令。

为什么这么做？这带来了两个关键优势：

批量执行与性能优化：你可以将多个命令组合起来，然后一次性执行。在底层，Tutu会尝试将多个ANSI序列或Windows API调用合并，减少对输出流的写入次数，这对于需要频繁更新屏幕的动画或交互应用来说，能显著提升性能和平滑度。
清晰的执行边界：通过Execute方法显式地执行命令，你能够精确控制输出何时真正发生（即“刷新”到终端）。这避免了在多线程环境下，来自不同线程的输出相互穿插、导致屏幕显示混乱的经典问题。

看看这个例子，它比直接调用Console.Write更有结构感：

using Tutu; using static Tutu.Commands.Style; using static Tutu.Commands.Cursor; // 传统方式（易混乱） Console.SetCursorPosition(10, 5); Console.ForegroundColor = ConsoleColor.Red; Console.Write("Hello"); Console.ResetColor(); // Tutu 命令式方式（清晰、可组合） Terminal.Out.Execute( MoveTo(10, 5), // 命令1：移动光标 SetForegroundColor(AnsiColor.Red), // 命令2：设置颜色 Print("Hello"), // 命令3：打印文本 ResetColor // 命令4：重置颜色 ); // 至此，所有效果才一次性应用到终端

2.3 依赖最小化与可裁剪性

作为一个底层库，Tutu非常注重轻量化和可控性。它只引入了极少数必要的依赖。例如，对于异步事件流（event-stream特性），它使用了System.Threading.Channels和Microsoft.Bcl.AsyncInterfaces这类 .NET 标准库或官方扩展，而不是重量级的第三方框架。

更重要的是，它通过C# 的特性标志（Feature Flags）来提供可裁剪性。如果你的应用只需要基本的颜色和光标功能，你可以在项目文件中禁用对鼠标或原始输入等高级特性的支持，从而减少最终编译产物的大小和潜在的开销。

<!-- 在你的 .csproj 文件中 --> <ItemGroup> <PackageReference Include="Tutu" Version="*" /> </ItemGroup> <!-- 默认包含所有特性 --> <!-- 或者，只启用你需要的特性 --> <ItemGroup> <PackageReference Include="Tutu" Version="*"> <ExcludeAssets>runtime</ExcludeAssets> </PackageReference> </ItemGroup> <PropertyGroup> <TutuFeatures>cursor,style</TutuFeatures> <!-- 只启用光标和样式特性 --> </PropertyGroup>

3. 核心功能深度解析与实操要点

3.1 光标控制：超越 Console.SetCursorPosition

原生的Console.SetCursorPosition只是最基本的光标移动。Tutu的Cursor命令提供了更精细、更语义化的控制。

相对移动：MoveUp(n),MoveDown(n),MoveLeft(n),MoveRight(n)。这在绘制相对变化的UI时非常有用，比如一个动态增长的进度条。
行与列的精确定位：MoveToPreviousLine(n),MoveToNextLine(n),MoveToColumn(x)。MoveToColumn特别有用，它能将光标移动到当前行的指定列，而无需知道当前的行坐标，常用于表格对齐。
光标状态管理：
- Hide/Show：在运行长时间任务或进行全屏渲染时，隐藏闪烁的光标可以提升视觉体验，避免干扰。
- SavePosition/RestorePosition：这是一对黄金组合。你可以保存当前光标位置，然后移动到别处输出一些临时信息（如状态提示），最后精确地恢复原位继续主流程的输出。这在实现“临时下拉提示”或“行内编辑”功能时不可或缺。

实操心得：光标保存/恢复的典型场景假设你在编写一个交互式命令行，用户输入时，你想在底部显示实时提示。错误的做法是每次提示都计算行数。正确的做法是：
用户输入前，执行SavePosition。
用户每按一个键，你MoveTo屏幕底部某行，输出提示，然后RestorePosition回到输入行。
这样无论屏幕如何滚动，输入光标始终在正确位置，提示信息也不会干扰主输入区。

3.2 样式与颜色：告别单调的16色

Tutu的颜色系统分为三个层次，兼容性从高到低：

16色基础色（AnsiColor）：这是兼容性最好的模式，对应传统的ConsoleColor。它包含了黑、红、绿、黄、蓝、洋红、青、白及其高亮变体。在所有支持的平台上都能稳定工作。
256色索引色（Ansi256Color）：提供了更丰富的色彩选择。在支持256色的终端（几乎所有现代Unix终端和Windows 10+的终端）上，你可以使用索引值（0-255）来指定颜色。这非常适合需要更多色彩层次但又不需要真彩色的图表或复杂UI。
RGB真彩色（RgbColor）：这是色彩控制的终极形态，允许你指定红、绿、蓝三个通道的值（各0-255）。但请注意兼容性：许多旧的终端模拟器、通过SSH连接的某些会话，或者Windows 10之前的原生控制台，可能不支持RGB。使用前最好通过Terminal.SupportsRgbColors属性进行检测。

除了颜色，文本属性（TextAttribute）也是一大亮点：

Bold（粗体）、Italic（斜体）、Underline（下划线）、CrossedOut（删除线）等。
重要提示：并非所有终端都支持所有属性（尤其是斜体和删除线）。Tutu会尽力输出正确的序列，但最终渲染效果取决于终端本身。在发布应用前，务必在你的目标终端上进行测试。

// 颜色与属性综合示例 Terminal.Out.Execute( SetForegroundColor(RgbColor.FromRgb(255, 100, 0)), // 橙色前景 SetBackgroundColor(Ansi256Color.FromIndex(28)), // 墨绿色背景 (256色) SetAttribute(TextAttribute.Bold), SetAttribute(TextAttribute.Underline), Print("绚丽且醒目的文本"), ResetAttributes // 重置所有样式（颜色和属性） );

3.3 终端控制：清屏、滚动与备用屏幕

这是构建全屏TUI应用的基础。

清除操作：Clear命令比Console.Clear()更精细。
- Clear(ClearType.All)：清空整个屏幕，光标移到左上角（同Console.Clear()）。
- Clear(ClearType.FromCursorDown)/Clear(ClearType.FromCursorUp)：清除从光标到屏幕底部/顶部的区域，保留另一部分。这在更新屏幕局部区域时非常高效。
- Clear(ClearType.CurrentLine)：仅清除光标所在行。常用于实现“行内更新”，比如一个动态刷新的单行进度条。
- Clear(ClearType.UntilNewLine)：清除从光标位置到当前行末尾的部分。适合用于命令行中“删除到词尾”这类操作的可视化。
滚动：ScrollUp(n)/ScrollDown(n)可以控制终端内容的滚动。这在实现自定义的滚动视图或日志查看器时很有用。
备用屏幕（Alternate Screen）：这是TUI应用的“杀手级”功能。通过EnableAlternateScreen/DisableAlternateScreen命令，你可以让应用切换到一个全新的、独立的屏幕缓冲区。当你的应用退出时，会自动切换回原来的主屏幕，并且主屏幕的内容完全不受干扰，就像什么都没发生过一样。这对于像vim,htop这样的全屏应用是标准做法。

// 进入全屏TUI模式的典型流程 try { Terminal.Out.Execute(EnableAlternateScreen, HideCursor); // ... 在这里绘制你的全屏UI ... RunMainLoop(); } finally { // 确保退出时恢复原状，即使发生异常 Terminal.Out.Execute(ShowCursor, DisableAlternateScreen); }

3.4 输入与事件处理：从按键到鼠标

Tutu将输入抽象为事件（Event），这是它与原生Console.ReadKey最大的不同。Console.ReadKey是阻塞的、同步的，并且信息有限。Tutu的事件系统是异步的、非阻塞的，并且信息丰富。

事件类型包括：

键盘事件：包含具体的键（KeyCode，如A,Enter,F1）和修饰键状态（KeyModifiers，如Ctrl,Alt,Shift是否被按下）。
鼠标事件：包括鼠标移动、按下、释放、拖动等。事件中包含了光标所在的精确行列坐标（(col, row)）以及被按下的鼠标按钮（左键、右键、中键等）。这是原生 .NET 几乎无法直接提供的功能。
终端大小改变事件：当用户调整终端窗口大小时，会触发此事件。你的TUI应用可以据此动态调整布局。

两种事件读取模式：

轮询模式：使用Terminal.Read()方法进行同步读取，或Terminal.TryRead(out var event)进行非阻塞尝试。适合简单的、单线程的交互。
异步流模式（需启用event-stream特性）：通过Terminal.Events()获取一个IAsyncEnumerable<Event>，你可以使用await foreach来异步地、响应式地处理所有输入事件。这是构建复杂、实时响应型TUI应用的推荐方式，因为它不会阻塞你的主渲染线程。

// 启用事件流特性的异步处理示例 using Tutu.Events; public static async Task RunAsync() { await foreach (var @event in Terminal.Events()) { switch (@event) { case KeyEventEvent keyEvent: if (keyEvent.Code == KeyCode.Char('q') && keyEvent.Modifiers == KeyModifiers.Control) { return; // 按 Ctrl+Q 退出 } HandleKey(keyEvent); break; case MouseEventEvent mouseEvent: HandleMouse(mouseEvent); // 处理鼠标点击、悬停等 break; case ResizeEventEvent resizeEvent: OnTerminalResized(resizeEvent.Size); // 动态调整UI布局 break; } } }

4. 实战：构建一个简单的交互式任务管理器TUI

让我们用一个具体的例子，将上述功能串联起来。我们将构建一个极简的、类似top的命令行任务管理器，它能显示进程列表，高亮选中行，并响应上下键和退出命令。

4.1 项目初始化与模型定义

首先，创建一个新的控制台应用，并添加Tutu包引用。

dotnet new console -n SimpleTaskManager cd SimpleTaskManager dotnet add package Tutu

我们定义一个简单的ProcessInfo类来模拟进程数据。

// ProcessInfo.cs public class ProcessInfo { public int Id { get; set; } public string Name { get; set; } public double CpuUsage { get; set; } // 百分比 public long MemoryMb { get; set; } }

4.2 主循环与UI渲染逻辑

核心是Render函数，它负责将进程列表和选中状态绘制到终端。

// Program.cs using Tutu; using static Tutu.Commands.Cursor; using static Tutu.Commands.Style; using static Tutu.Commands.Terminal; using System.Diagnostics; public class Program { private static List<ProcessInfo> _processes = new(); private static int _selectedIndex = 0; private static bool _shouldQuit = false; public static async Task Main() { // 初始化模拟数据 RefreshProcessList(); // 进入备用屏幕并隐藏光标 Terminal.Out.Execute(EnableAlternateScreen, HideCursor, Clear(ClearType.All)); try { // 主循环 while (!_shouldQuit) { Render(); await HandleInputAsync(); // 异步处理输入 await Task.Delay(100); // 控制刷新频率，避免CPU占用过高 } } finally { // 退出前恢复终端状态 Terminal.Out.Execute(ShowCursor, DisableAlternateScreen); } } private static void Render() { var commands = new List<ICommand> { MoveTo(0, 0), Print("简易任务管理器 (按 ↑/↓ 选择，按 'q' 退出)"), MoveTo(0, 2) }; // 打印表头 commands.Add(SetForegroundColor(AnsiColor.Yellow)); commands.Add(Print($"{"PID",-8} {"进程名",-20} {"CPU%",-8} {"内存(MB)",-10}")); commands.Add(ResetColor); for (int i = 0; i < _processes.Count; i++) { var proc = _processes[i]; commands.Add(MoveTo(0, 3 + i)); // 移动到每一行的起始位置 // 高亮选中行 if (i == _selectedIndex) { commands.Add(SetBackgroundColor(AnsiColor.Blue)); commands.Add(SetForegroundColor(AnsiColor.White)); } else { commands.Add(ResetColor); // 确保非选中行使用默认颜色 } // 格式化并打印进程信息 string line = $"{proc.Id,-8} {proc.Name,-20} {proc.CpuUsage,7:F1}% {proc.MemoryMb,9}"; commands.Add(Print(line)); commands.Add(ResetColor); // 重置颜色，为下一行做准备 } // 一次性执行所有绘制命令，避免闪烁 Terminal.Out.Execute(commands.ToArray()); } private static async Task HandleInputAsync() { // 使用非阻塞方式读取输入 if (Terminal.TryRead(out var @event)) { if (@event is KeyEventEvent keyEvent) { switch (keyEvent.Code) { case KeyCode.Up: _selectedIndex = Math.Max(0, _selectedIndex - 1); break; case KeyCode.Down: _selectedIndex = Math.Min(_processes.Count - 1, _selectedIndex + 1); break; case KeyCode.Char('q'): _shouldQuit = true; break; } } } // 简单模拟数据更新 RefreshProcessList(); } private static void RefreshProcessList() { // 这里简化处理，实际应从System.Diagnostics.Process获取 // 我们模拟一些动态变化的数据 var rnd = new Random(); if (!_processes.Any()) { _processes = Enumerable.Range(1, 15).Select(i => new ProcessInfo { Id = 1000 + i, Name = $"Process_{i}", CpuUsage = rnd.NextDouble() * 50, MemoryMb = rnd.Next(10, 500) }).ToList(); } else { // 模拟CPU使用率的轻微波动 foreach (var p in _processes) { p.CpuUsage = Math.Max(0, p.CpuUsage + (rnd.NextDouble() - 0.5) * 5); } } } }

4.3 关键实现细节剖析

双缓冲与无闪烁渲染：注意Render方法最后，我们将所有绘图命令收集到一个List<ICommand>中，然后通过一次Terminal.Out.Execute调用批量执行。这是实现平滑、无闪烁UI的关键。如果每设置一个颜色或移动一次光标就执行一次，终端会频繁刷新，导致明显的闪烁。
状态管理：我们使用_selectedIndex和_processes来维护应用状态。UI渲染 (Render) 是纯函数，它只依赖于当前状态。输入处理 (HandleInputAsync) 负责修改状态。这种分离使得逻辑清晰，易于测试和扩展。
输入处理策略：这里使用了Terminal.TryRead进行非阻塞轮询。在主循环的每次迭代中，我们检查是否有按键事件，然后立即返回，这样不会阻塞UI的定期刷新。对于更复杂的、需要同时等待多个事件源（如输入和定时器）的应用，使用event-stream特性的异步流模式会是更好的选择。
资源清理：整个UI逻辑被包裹在try-finally块中。无论主循环是正常退出还是因异常中断，finally块中的代码都会确保光标被重新显示，并且终端切换回主屏幕。这是一个必须遵守的最佳实践，可以避免把终端留在混乱的状态。

5. 进阶技巧与性能优化

5.1 使用“原始模式”进行精细输入控制

默认情况下，终端处于“行缓冲”模式：你的输入会先显示在屏幕上，直到按下回车键，程序才能读到整行内容。对于需要实时响应单个按键的TUI应用（如Vim），这显然不行。

Tutu提供了EnableRawMode命令。在原始模式下：

按键会立即被发送给程序，无需等待回车。
特殊字符（如Ctrl+C,Ctrl+Z）会作为普通字符事件传递，而不会触发操作系统的默认中断信号。这意味着你的应用需要自己处理这些组合键的退出逻辑。
终端自身的回显（Echo）功能被禁用。你的程序需要完全负责在屏幕上显示任何内容，这给了你最大的控制权。

重要警告：启用原始模式后，务必、务必、务必在程序退出前（或在finally块中）调用DisableRawMode来恢复终端设置。否则，用户的shell会话可能会处于一个无法正常输入的状态，只能通过reset命令或关闭终端来恢复。

Terminal.Out.Execute(EnableRawMode); try { // 在此进行需要即时按键响应的交互 await RunReactiveUiAsync(); } finally { Terminal.Out.Execute(DisableRawMode); // 绝对不可或缺！ }

5.2 多线程环境下的安全输出

Tutu的核心对象（如Terminal.Out）是线程安全的（Send + Sync）。这意味着你可以从多个线程安全地调用Execute方法。然而，这并不意味着你可以随意从任何线程输出。

最佳实践是：将所有终端输出集中到主线程或一个专用的“渲染线程”中。其他工作线程（如网络线程、计算线程）应该通过线程安全的队列（如System.Threading.Channels.Channel）将需要显示的消息发送给渲染线程，由渲染线程统一调度和执行Execute命令。

这样做的好处是：

避免输出错乱：来自不同线程的输出命令如果交织执行，会导致屏幕内容混乱。
简化性能优化：渲染线程可以更容易地实现命令批处理，减少系统调用。
逻辑清晰：UI更新逻辑集中在一处，便于维护和调试。

5.3 性能敏感场景的优化策略

对于需要极高刷新率的应用（如终端游戏、实时数据仪表盘），可以考虑以下优化：

最小化输出区域：不要每次刷新都重绘整个屏幕。只重绘发生变化的部分。利用Clear(ClearType.CurrentLine)或Clear(ClearType.UntilNewLine)进行局部清除和重写。
重用命令列表：对于静态的UI框架部分，可以预先构建好命令列表。在每次渲染时，只动态生成数据变化部分的命令，然后与静态命令列表合并执行。
谨慎使用RGB颜色和复杂属性：输出RGB序列（如\x1b[38;2;R;G;Bm）比输出基础色序列（如\x1b[31m）要长得多。在极端性能要求下，可以考虑限制使用RGB色，或使用256色替代。
基准测试：使用Stopwatch对你的渲染循环进行基准测试。确保单次渲染（包括所有业务逻辑和Execute调用）的时间远小于你的目标帧间隔（例如，目标60fps，则渲染时间应小于16ms）。

6. 常见问题与排查技巧实录

即使有了Tutu这样的优秀抽象，在跨平台开发TUI应用时，你仍可能遇到一些“坑”。以下是我在实际项目中积累的一些常见问题和解决方法。

6.1 颜色或样式不显示/显示异常

这是最常见的问题，通常源于终端兼容性或初始化顺序。

症状：代码设置了颜色，但终端没有显示任何颜色，或显示了错误的颜色。
排查步骤：
1. 检查终端类型：首先确认你使用的终端是否支持ANSI颜色。在Windows上，cmd.exe和旧版PowerShell需要系统启用VT支持。Windows Terminal、ConEmu、以及Linux/macOS上的大多数终端（如GNOME Terminal, iTerm2, kitty）都支持良好。
2. 验证支持级别：在程序启动时，可以输出Terminal.SupportsAnsiCodes和Terminal.SupportsRgbColors的值进行调试。
3. 重置状态：确保在每次样式变化序列的末尾正确使用了ResetColor或ResetAttributes。一个常见的错误是设置了颜色后忘记重置，导致后续所有输出都继承了该样式。
4. 查看原始输出：有时终端主题会影响颜色显示。可以尝试将输出重定向到文件（如./yourapp > output.txt），然后用文本编辑器打开查看文件中是否包含ANSI转义码（类似^[[31m的字符）。如果有，说明程序输出正确，是终端渲染的问题。

6.2 光标位置错乱或屏幕闪烁

这通常与渲染逻辑和缓冲有关。

症状：UI元素出现在错误的位置，或者屏幕在更新时剧烈闪烁。
解决方案：
- 确保使用批量执行：这是消除闪烁的最有效方法。绝对避免在循环中连续调用多个独立的Execute。
- 检查坐标计算：MoveTo(x, y)中的x是列（从0开始），y是行（从0开始）。屏幕左上角是(0, 0)。常见的错误是行列用反，或者对基于1的索引和基于0的索引产生混淆。
- 考虑终端大小：在渲染前，通过Terminal.Size()获取当前的终端大小（列数和行数）。确保你的UI坐标不会超出这个范围，否则行为是未定义的。监听ResizeEvent来动态调整布局。

6.3 输入无响应或行为怪异

这通常与原始模式和事件读取方式有关。

症状：按键盘没反应，或者按一下产生多个字符，或者无法用Ctrl+C中断程序。
排查步骤：
1. 确认已启用原始模式：如果你需要即时按键响应，必须在开始读取输入前调用EnableRawMode。
2. 检查事件读取循环：确保你的Read或TryRead调用在正确的主循环中。如果使用异步流Events()，确保你正在await foreach它，并且没有其他地方阻塞了异步上下文。
3. 处理信号：在原始模式下，Ctrl+C(SIGINT) 和Ctrl+Z(SIGTSTP) 等信号会被作为普通键盘事件传递。你的程序需要显式检查这些组合键并做出响应（例如退出程序）。一个健壮的处理方式如下：
```
if (keyEvent.Code == KeyCode.Char('c') && keyEvent.Modifiers == KeyModifiers.Control) { // 执行清理操作（如DisableRawMode） Environment.Exit(0); }
```

6.4 在管道或重定向时行为异常

症状：当你的程序输出被重定向到文件（> file.txt）或管道（|）时，程序崩溃或输出乱码。
原因：Tutu的许多功能（如光标移动、清屏）依赖于终端是交互式的（即是一个TTY）。当标准输出被重定向到非终端设备时，这些控制序列就没有意义，甚至会导致问题。

解决方案：在尝试执行任何终端控制命令前，先检查Terminal.IsTty属性。

if (Terminal.IsTty) { // 安全地执行光标移动、清屏等操作 Terminal.Out.Execute(MoveTo(0, 0), Clear(ClearType.All)); } else { // 非交互式环境，只输出纯文本内容 Terminal.Out.Execute(Print("非交互模式，输出简化文本\n")); }

6.5 与其他控制台输出混合使用

症状：在使用了Tutu的程序中，混用Console.WriteLine导致输出位置和样式混乱。
建议：尽量避免混合使用。Tutu和System.Console都操作同一个标准输出流，但它们的缓冲和状态管理机制不同。一旦你开始使用Tutu，最好就坚持使用它的Terminal.Out.Execute(Print(...))来进行所有输出。如果必须使用第三方库，而该库只接受TextWriter（如Console.Out），你可以考虑使用Terminal的Writer适配器，或者将输出重定向。