Go 语言如何开发一个简单的交互式 Shell

bufio.Scanner 是读取用户输入最稳妥的选择，因其按行切割、缓冲安全且不因超长输入 panic；需显式处理换行符、检查 scanner.Err()、用 flag 包结构化解析命令、监听 SIGINT 与 EOF、健壮输出 prompt。

先抛出几个关键判断。Go 标准库并没有提供像 Python 的 readline 那样开箱即用、自带历史记录和行编辑功能的模块。所以，当动手搭建一个交互式 Shell 时，bufio.Scanner 是最轻量级、最可控的选择，甚至可以说，它是目前最稳的路子。它默认按行切割，缓冲安全，最关键的是，不会因为输入过长就直接 panic——这点就比直接用 fmt.Scanln 或 os.Stdin.Read 强出一个维度。

不过，很多人在实际开发中容易在细节上翻车。最常见的两个坑：一是忘了处理换行符，二是循环结束后没有去检查 scanner.Err()。结果就是，用户按下 Ctrl+D 后，程序要么卡住不动，要么静默失败——这种问题的排查成本不低。

• 循环开始前，建议显式调用 scanner.Split(bufio.ScanLines)。虽然这已经是默认行为，但写出来既是提醒自己，也让代码的意图更清晰。
• 每次 scanner.Scan() 成功之后，用 strings.TrimSpace(scanner.Text()) 把首尾的空格和换行统统清掉，避免一些诡异的隐藏字符闯进解析流程。
• 循环退出后，一定要检查 if err := scanner.Err(); err != nil，把真实的 I/O 错误和正常的 EOF 区分开——这个步骤省不了。

命令解析别硬写 strings.Split，用 flag 包预埋扩展性

哪怕现在需求特别简单，只有 exit 和 help 两个命令，也建议直接用 flag.NewFlagSet 来模拟子命令结构。为什么？因为一旦项目开始迭代，写到第 5 个命令的时候，那种嵌套的 if/else if 结构绝对会失控。更别提后面还要支持类似 ls -l /tmp 这种带参数的指令，统一个解析逻辑才能避免陷入维护泥潭。

项目实践中可以这样组织代码结构：

cmd := flag.NewFlagSet("ls", flag.ContinueOnError)
long := cmd.Bool("l", false, "use long listing format")
path := cmd.String("path", ".", "target directory")
if err := cmd.Parse(args[1:]); err == nil {
    // 处理 ls 逻辑
}

• 每个命令对应一个独立的 flag.FlagSet，彼此互不干扰，逻辑清晰。
• 先用 strings.Fields(line) 把原始输入切成切片，然后把切片传给对应 FlagSet 的 Parse() 方法。
• 错误处理时，需要注意单独捕获 flag.ErrHelp，避免把冗余的 usage 信息一股脑打印出来。

退出要响应 Ctrl+C 和 Ctrl+D 两种信号

如果只依赖 scanner.Scan() == false 来捕获退出，那么能处理的只有 Ctrl+D（即 EOF）。但在实际使用中，绝大多数用户更习惯用 Ctrl+C 来中断操作。如果这个信号没有被妥善处理，后果可能是进程残留、终端混乱，更严重的情况下 stdin 会被直接锁死，程序再也无法正常接收输入。

正确的做法是借助 os/signal 包显式监听 os.Interrupt（即 SIGINT）：

• 单独启动一个 goroutine 进行信号监听：signal.Notify(sigChan, os.Interrupt)
• 主循环里用 select 同时等待 scanner 结果和信号，只要任意一个触发，程序就执行退出流程。
• 收到信号后，先调用 scanner.Bytes() 清空缓冲区，再执行 os.Exit(0)，这样做可以避免 panic 堆栈污染终端输出。

交互提示符（prompt）别用 fmt.Print 硬拼，考虑终端兼容性

很多人习惯用 fmt.Print("> ") 来打印提示符，这个写法在大多数标准终端上确实没问题。但一旦用户用的是 zsh 主题、tmux 分屏，或者是 Windows PowerShell，提示符的光标位置可能错位，甚至直接被吞掉——这种问题很难复现，但一旦遇到就非常影响体验。

一个更健壮的做法是：用 fmt.Fprint(os.Stdout, "> ") 配合 os.Stdout.Sync() 强制刷新缓冲区。如果后续需要支持颜色，直接嵌入 \033[1;32m>\033[0m 这类 ANSI 转义序列即可，完全不需要引入第三方库。

• 尽量避免在 prompt 字符串里直接拼接变量，比如 "[" + user + "]>" 这种写法。除非你确定 user 变量中绝不含任何控制字符——否则就是给自己埋雷。
• 当用户粘贴多行代码时，提示符只应在第一行出现，后续行应保持空白。这个行为恰好由 Scanner 的行模式天然保证，无需额外处理。
• 如果在 Windows 上开发，要特别留意：cmd.exe 对 ANSI 转义序列的支持非常有限。推荐优先使用 WSL 或 Git Bash 进行测试，可以避免很多环境兼容性问题。

开发一个可用的交互式 Shell，真正的难点其实不在于启动 REPL 的那几行代码。关键在于：让每一行输入都能干净、完整地进入解析流程；让每一次中断都能干净、彻底地释放资源；让每一个错误都能明确、直观地反馈到终端。正是这些细节的逐个解决，才真正划定了“能用”与“好用”之间的分水岭。