fmt.scan易卡住因跳过换行符致缓冲区残留，读带空格字符串会截断；应统一用bufio.scanner处理输入，并用signal.notify+quit通道优雅响应ctrl+c。
用 fmt.Scan 读输入时为啥总卡住或漏读？
fmt.Scan 看起来最简单，但实际交互中容易出问题：它跳过所有空白（包括换行），只在遇到非空白字符后开始读，且读到下一个空白就停。这意味着用户输完按回车，换行符会留在缓冲区，下一次 fmt.Scan 可能直接“读到空”然后卡住。
- 如果用户要输带空格的字符串（比如文件路径
/usr/local/bin），fmt.Scan会只读/usr/local/bin前半截 - 混合使用
fmt.Scan和bufio.NewReader(os.Stdin).ReadString('\n')时，前者残留的换行会让后者立刻返回空字符串 - 它不处理 EOF，Ctrl+D 会导致 panic，除非手动 recover
更稳的做法是统一用 bufio.Scanner：
scanner := bufio.NewScanner(os.Stdin)
for scanner.Scan() {
line := strings.TrimSpace(scanner.Text())
if line == "" { continue }
// 处理一行
}
if err := scanner.Err(); err != nil {
log.Fatal(err) // 包括 EOF、I/O 错误等
}怎么让命令行工具支持 Ctrl+C 优雅退出而不崩？
Golang 默认对 SIGINT（即 Ctrl+C）不做处理，进程直接退出，中间状态（比如正在写文件、发请求）来不及清理。这不是“崩溃”，但行为不可控。
- 不要用
os.Interrupt单独监听——它只是信号值，没绑定行为 - 必须用
signal.Notify显式注册，并配一个干净的退出通道 - 主 goroutine 要 select 等待退出信号，不能靠
time.Sleep或死循环硬等
quit := make(chan os.Signal, 1)
signal.Notify(quit, os.Interrupt, syscall.SIGTERM)
// ... 启动你的主逻辑（比如 scanner 循环）
go func() {
<-quit
fmt.Println("\n正在退出...")
// 这里做清理：关闭文件、取消 context、flush 日志等
os.Exit(0)
}()注意：如果主逻辑在阻塞系统调用（如 http.ListenAndServe）里，需额外传入带 cancel 的 context.Context 才能中断。
立即学习“go语言免费学习笔记（深入）”；
输出 ANSI 颜色后终端乱码或颜色不生效？
不是所有终端都默认支持 ANSI 转义序列，Windows cmd 尤其典型：Win10 1607+ 需先调用 syscall.SetConsoleMode 开启虚拟终端处理；旧版 PowerShell 或 Git Bash 则可能把 3[32m 当普通字符打印出来。
- 先检查环境：
os.Getenv("TERM")是xterm-256color或screen通常没问题；空或cygwin要小心 - Windows 下别直接写
\033，用fmt.Sprintf("\x1b[%dm", code)更稳妥 - 第三方库如
github.com/mattn/go-colorable会自动适配 stdout/stderr 是否为真实终端，比手写runtime.GOOS == "windows"判断更可靠
示例兼容写法：
import "github.com/mattn/go-colorable" w := colorable.NewColorableStdout() fmt.Fprint(w, "\x1b[32mOK\x1b[0m\n")
为什么用 os.Stdin 重定向输入时程序行为异常？
比如 echo "hello" | ./mytool，你预期读到 "hello"，结果 scanner.Scan() 返回 false，或者读到空字符串。常见原因有：
- 忘了检查
scanner.Err()：管道关闭后scanner.Scan()返回 false，但错误可能是io.EOF（正常）或io.ErrUnexpectedEOF（异常） - 在循环外提前 close 了
os.Stdin（极少见，但某些封装库会干这事） - 使用了
os.Stdin.Read()之类底层读取，和bufio.Scanner共享底层 buffer，导致数据被吃掉
安全做法是始终以错误为判断依据：
scanner := bufio.NewScanner(os.Stdin)
for {
ok := scanner.Scan()
if !ok {
if errors.Is(scanner.Err(), io.EOF) {
break // 正常结束
}
log.Fatal("读取输入失败：", scanner.Err())
}
process(scanner.Text())
}交互式场景和管道场景本质一致，别写两套逻辑。真正的分界点在于是否需要响应实时按键（比如方向键），那得上 golang.org/x/term。
有些边界情况没法绕开：比如用户输入超长行（默认 64KB 限制），scanner.Scan() 会直接报错，这时得用 scanner.Buffer(make([]byte, 0, 1MB), 1MB) 手动扩容——但得想清楚，命令行工具真需要处理几 MB 的单行输入吗？
