Go 命令行工具怎么同时读标准输入和文件：参数设计、流式解析与错误退出码

不少用Go写的命令行小工具，一开始只支持接收单个文件参数，碰到管道场景就会卡壳：上游程序已经把数据顺着管道传过来，工具还在等着用户输入文件名。我们直接写一个可跑通的Go日志筛选器，约定“有文件参数就读文件，没有参数就读标准输入”，逐行检查状态字段，只输出包含 status=error 的记录。

把文件和管道都看成同一个 io.Reader，入口只负责选择数据源，后面的解析、校验和输出逻辑就能共用同一条路径；输入错误返回2，业务筛选流程正常完成返回0。

先把命令行的使用场景定下来

这个小工具叫 logpick，输入是单行一条的文本日志：

time=10:00 level=info service=pay status=ok
time=10:01 level=error service=pay status=error request=7f31
time=10:02 level=warn service=stock status=retry

使用方式贴合Unix工具的通用使用习惯：

go run . app.log
cat app.log | go run .
go run . --service=pay app.log

传一个文件名就直接打开对应文件；不传文件名就读取 os.Stdin。文件和管道不同时作为输入源，入口规则越简单，后续的解析逻辑越容易做单元测试。

环境准备：只用标准库搭出最小项目

新建文件夹并初始化Go模块：

mkdir logpick
cd logpick
go mod init example.com/logpick

项目暂时只留一个 main.go。先把入口逻辑和错误边界理清楚，后续有需求再考虑扩展功能。

核心代码：来源选择和解析共用一条路径

flag 负责接收可选的服务名参数，文件名保留为位置参数。文件和标准输入最终都返回 io.Reader，所以筛选函数不需要感知数据到底来自哪里。

package main

import (
    "bufio"
    "errors"
    "flag"
    "fmt"
    "io"
    "os"
    "strings"
)

func main() {
    service := flag.String("service", "", "only keep one service")
    flag.Parse()

    input, closeInput, err := openInput(flag.Args())
    if err != nil {
        fmt.Fprintln(os.Stderr, err)
        os.Exit(2)
    }
    defer closeInput()

    if err := filterLogs(input, os.Stdout, *service); err != nil {
        fmt.Fprintln(os.Stderr, err)
        os.Exit(2)
    }
}

func openInput(args []string) (io.Reader, func(), error) {
    if len(args) == 0 {
        return os.Stdin, func() {}, nil
    }
    if len(args) > 1 {
        return nil, func() {}, fmt.Errorf("only one input file is supported")
    }
    file, err := os.Open(args[0])
    if err != nil {
        return nil, func() {}, fmt.Errorf("open %s: %w", args[0], err)
    }
    return file, func() { _ = file.Close() }, nil
}

func filterLogs(input io.Reader, output io.Writer, service string) error {
    reader := bufio.NewReader(input)
    for {
        line, err := reader.ReadString('\n')
        if strings.TrimSpace(line) != "" && strings.Contains(line, "status=error") {
            if service == "" || strings.Contains(line, "service="+service) {
                if _, writeErr := io.WriteString(output, line); writeErr != nil {
                    return fmt.Errorf("write output: %w", writeErr)
                }
            }
        }
        if err != nil {
            if errors.Is(err, io.EOF) {
                return nil
            }
            return fmt.Errorf("read input: %w", err)
        }
    }
}

ReadString('\n') 在最后一行没有换行符时，可能同时返回内容和 io.EOF，所以要先处理读到的非空内容，再判断返回的错误。文件只在成功打开后才注册关闭动作，打开失败不会触发无效的关闭调用。

本地运行：三组输入就能覆盖核心边界

准备 app.log：

time=10:00 level=info service=pay status=ok
time=10:01 level=error service=pay status=error request=7f31
time=10:02 level=error service=stock status=error request=8a20

直接传入本地文件路径时，只会输出符合条件的两条错误记录：

go run . app.log
# time=10:01 level=error service=pay status=error request=7f31
# time=10:02 level=error service=stock status=error request=8a20

接入管道后，内部读取路径完全没有变化：

cat app.log | go run . --service=pay
# time=10:01 level=error service=pay status=error request=7f31

指定不存在的文件时，程序会往标准错误输出打印打开失败的提示，并且返回退出码 2：

go run . missing.log >/tmp/logpick.out
echo $?
# 2

不要只盯着终端有没有打印内容看。对调用这个工具的上层脚本来说，进程返回的退出码比一行文字提示更可靠。

接入脚本时，先约定空结果和坏输入的边界

当前实现里，“没有匹配到任何记录”属于正常处理完成，退出码仍是 0；“文件不存在、传入参数过多、读取数据失败”这类场景才返回 2。这种区分逻辑很适合做定时巡检场景：上层脚本可以把空结果当成没有异常，把输入类错误当成任务执行失败。

如果业务需要把“发现指定错误日志”也改成非零退出码，不要直接改写底层的读取函数。让筛选函数返回匹配到的记录总数，再由 main 统一决定输出内容和最终退出码，后续维护成本会低很多。读取、筛选、命令行策略各自只负责一块逻辑，后面新增JSON输出或者时间范围过滤这类功能时，不同模块的改动不会互相干扰。

常见问题

为什么不用 bufio.Scanner？

Scanner 写短行代码更简洁，但它自带默认的token大小上限。日志里经常会出现很长的堆栈或者完整请求体，用 Reader.ReadString 可以更灵活地控制读取行为。

文件参数和标准输入能同时读取吗？

可以自行设计规则，但第一版实现最好只允许单一输入源。单一来源的实现逻辑能让数据顺序、错误归属和资源关闭时机都更清晰，真的需要拼接多个输入时再补充明确的参数定义就好。

为什么错误信息要写到标准错误？

标准输出专门留着输出筛选后的结果，标准错误用来打印诊断类信息。这样调用方可以把结果重定向到文件，同时还能在终端看到文件打开或者数据读取失败的具体原因。

退出码一定要用 2 吗？

不一定。核心是团队内部先约定好不同退出码的含义，后续保持统一就行。示例里用0表示处理流程全部完成、2表示输入或读取类错误，上层脚本可以直接按这个约定做下一步判断。

验收清单

• 传本地文件时能正确筛出 status=error，并且正常关闭文件句柄。
• 不传文件参数时能从管道读取数据，就算最后一行没有换行符也不会丢内容。
• 指定 --service 后只会输出对应服务的目标日志。
• 文件不存在、参数过多、读取失败这类场景，都有标准错误提示和稳定的退出码。
• 空输入场景属于正常完成还是异常报错，已经提前写进调用约定。

这类小工具的核心从来不是功能有多复杂，而是入口边界的处理是否稳定。把所有输入源统一成 io.Reader，再把筛选逻辑和退出码策略拆开实现，后续要接入压缩日志、定时任务或者流水线时，需要改动的代码量会少很多。