liner比readline更适合Go CLI分发，因其纯Go实现、无CGO依赖，支持静态编译与跨平台一致运行；可避免macOS/Linux上因系统readline库缺失导致的链接错误，开箱即用历史记录与行编辑功能。
为什么 liner 比 readline 更适合 Go CLI 工具分发
因为 bobappleyard/readline 依赖 CGO 和系统级 GNU readline 库，而 github.com/peterh/liner 是纯 Go 实现，静态编译后无外部依赖。你在 macOS 上用 go build -ldflags="-s -w" 打包一个二进制，它就能在任意 Linux/macOS 机器上直接运行——这点对 CLI 工具的用户安装体验至关重要。
常见错误现象包括：dyld: Library not loaded: /usr/local/opt/readline/lib/libreadline.8.dylib（macOS）、undefined reference to `rl_bind_key'（Linux 交叉编译失败）。这些都不是你的代码问题，而是链接时环境缺失导致的。
- liner 默认启用历史记录、Ctrl+A/E/K/U 等编辑键，开箱即用
- 它不支持多行输入或语法高亮，但绝大多数 CLI 场景（如
etcdctl、golangci-lint）根本不需要这些 - 如果你需要补全，调用
l.SetCompleter()注册函数即可，无需额外配置终端模式
liner 的自动补全函数怎么写才不卡住主线程
补全逻辑默认在用户按下 Tab 时同步执行，如果补全函数里做了网络请求、读大文件或调用慢命令，整个 CLI 就会卡住——这不是 liner 的 bug，是你没把耗时操作移出主线程。
正确做法是：补全函数只做快速本地匹配（比如查内存里的命令列表、前缀过滤），所有 I/O 操作提前预热或异步缓存。例如：
立即学习“go语言免费学习笔记（深入）”；
l.SetCompleter(func(line string) []string {
// ✅ 快速返回：从预加载的 commands 切片中筛选
var matches []string
for _, cmd := range commands {
if strings.HasPrefix(cmd, line) {
matches = append(matches, cmd)
}
}
return matches
})
- 不要在
SetCompleter回调里调用exec.Command或http.Get - 如果必须动态获取补全项（比如远程服务命令列表），应在程序启动时用 goroutine 预取并缓存到 map 中
- liner 不提供异步补全接口，强行用 channel + select 做“伪异步”反而增加复杂度，得不偿失
Windows 下 liner 的 ANSI 颜色输出为什么有时失效
不是 liner 的问题，是 Windows 终端默认禁用虚拟终端处理。即使你用了 \x1b[32mOK\x1b[0m，控制台也可能原样打印转义序列。
解决方法很简单：在 main() 开头加一段初始化代码，调用 Windows API 启用 VT 模式：
if runtime.GOOS == "windows" {
kernel32 := syscall.NewLazySystemDLL("kernel32.dll")
proc := kernel32.NewProc("SetConsoleMode")
h, _ := syscall.Open("CONOUT$", syscall.O_RDWR, 0)
proc.Call(uintptr(h), 0x0007)
}
- 这个调用只需一次，之后所有 ANSI 都能正常渲染
- liner 本身不干预输出流，所以 color.Output、log.Printf 等都能直通生效
- 如果你用
golang.org/x/term或mattn/go-colorable，它们内部也做了类似事情，但 liner 不强制你引入这些依赖
liner 和 go-prompt 的关键差异在哪
选 github.com/c-bata/go-prompt 还是 github.com/peterh/liner？核心区别不在功能多寡，而在维护边界和使用成本。
go-prompt 功能更重：支持多级补全、语法高亮、自定义样式、鼠标事件；但它的 API 更复杂，生命周期管理容易出错（比如忘记调用 prompt.Close() 导致 goroutine 泄漏），且文档更新滞后。
- liner：适合大多数工具，API 就两个核心方法 ——
NewLiner()和Prompt()，稳定、小、易测试 - go-prompt：适合需要交互式菜单、命令树导航的场景（比如数据库 CLI），但你要承担更多状态管理责任
- 两者都不支持 Windows Terminal 的新特性（如 emoji 渲染、真彩色），这不是缺陷，是定位使然
真正容易被忽略的是：liner 的历史记录默认保存在 ~/.history，而 go-prompt 默认不持久化——如果你没显式调用 SaveHistory()，每次重启 CLI 都得重输命令。这个细节在调试阶段很难察觉，上线后却直接影响用户留存率。
