tail -f 命令之所以成为日志排查的标准动作，是因为它能够在文件末尾追加新内容时立刻把增量数据送到终端。要在 Go 程序里复刻这一能力，最核心的问题不是把文件读一遍，而是让读取操作持续停留在文件尾部，并不断感知新增字节。常见的做法是先打开文件、通过 Seek 把偏移量移动到末尾，然后进入读取循环；但一个能在生产环境工作的追踪器还必须处理文件轮转、按行缓冲和并发控制。本文从最小可用版本开始，逐步加入这些细节。

最小实现：Seek 定位与 Read 循环

实现文件追踪的第一步是拿到文件当前的末尾偏移量。在 Go 语言中可以用 os.Open 打开文件，再调用 file.Seek(0, io.SeekEnd) 把读写位置定位到文件末尾。这样后续的 Read 调用只会读取追加到文件末尾的新字节，而不会把历史内容重复输出。这个操作对普通本地文件非常稳定，不会因为文件大小发生变化而失败。

一个最简单的追踪循环如下：

package main
import (
    "io"
    "log"
    "os"
    "time"
)
func tailFile(path string) {
    f, err := os.Open(path)
    if err != nil {
        log.Fatal(err)
    }
    defer f.Close()
    _, err = f.Seek(0, io.SeekEnd)
    if err != nil {
        log.Fatal(err)
    }
    buf := make([]byte, 1024)
    for {
        n, err := f.Read(buf)
        if n > 0 {
            os.Stdout.Write(buf[:n])
        }
        if err == io.EOF {
            time.Sleep(500 * time.Millisecond)
            continue
        }
        if err != nil {
            log.Printf("read error: %v", err)
            return
        }
    }
}

这段代码在读取到文件末尾遇到 io.EOF 时会休眠 500 毫秒，然后再次尝试读取。它能实现最基本的增量输出，但存在明显不足：休眠间隔决定了检测延迟，间隔太短会空转占用 CPU，间隔太长又无法及时看到新内容。此外，如果日志轮转工具把原文件重命名并创建了新文件，这个循环仍然持有旧文件的句柄，新文件的内容永远不会被读取。

文件被截断也是常见边界情况。很多日志系统采用 copytruncate 方式轮转，旧的偏移量会大于新的文件大小，如果继续从旧偏移量读取，会丢失前一段内容。因此仅靠 Seek 到末尾并循环 Read 远远不够，还需要引入更可靠的检测机制。

从轮询到事件通知：fsnotify 与 inode 检测

为了避免频繁空转，不少开发者会想到用文件系统事件通知库。Go 生态里 fsnotify 是使用最广泛的跨平台文件监听库，它可以监听文件的写入、创建、删除、重命名等事件。当目标文件发生写操作时，程序收到事件后再去读取，理论上可以降低 CPU 占用，同时获得更快的响应。

使用 fsnotify 监听文件写入事件的基本结构如下：

watcher, err := fsnotify.NewWatcher()
if err != nil {
    log.Fatal(err)
}
defer watcher.Close()
err = watcher.Add(path)
if err != nil {
    log.Fatal(err)
}
for {
    select {
    case event, ok := <-watcher.Events:
        if !ok {
            return
        }
        if event.Op&fsnotify.Write == fsnotify.Write {
            readNewData(f)
        }
    case err, ok := <-watcher.Errors:
        if !ok {
            return
        }
        log.Printf("watch error: %v", err)
    }
}

但这套方案并非完美。fsnotify 监听的是文件路径，一旦 logrotate 先重命名原文件再创建新文件，监听器可能失效或者指向旧文件。更稳妥的做法是监听文件所在目录，通过捕获 Create 或 Rename 事件来判断是否需要重新打开目标文件。与此同时，还需要比较文件句柄的 inode 是否与路径当前指向的 inode 一致。

下面是一个按需重新打开文件的辅助函数，它通过 os.SameFile 判断当前句柄和路径是否指向同一个文件：

func reopenIfRotated(path string, current *os.File) (*os.File, error) {
    pathInfo, err := os.Stat(path)
    if err != nil {
        return nil, err
    }
    fileInfo, err := current.Stat()
    if err != nil {
        return nil, err
    }
    if os.SameFile(pathInfo, fileInfo) {
        return current, nil
    }
    current.Close()
    f, err := os.Open(path)
    if err != nil {
        return nil, err
    }
    _, err = f.Seek(0, io.SeekEnd)
    if err != nil {
        f.Close()
        return nil, err
    }
    return f, nil
}

这个函数可以放在定时检查逻辑中，也可以和目录监听事件配合使用。当发现文件大小比当前偏移量小，说明发生了截断，需要把偏移量重置到文件开头；当 os.SameFile 返回 false，说明路径已经被替换，需要关闭旧句柄并打开新文件。只有把这两类情况都覆盖到，追踪器才能在常见日志轮转策略下不丢数据。

生产级细节：缓冲读取、按行输出与多文件并发

直接调用 Read 读取到的字节块是任意长度的，可能把一行日志从中间截断，下游的日志采集器如果按行解析就会出现脏数据。使用 bufio.Reader 可以方便地按行读取，同时减少系统调用次数。bufio.Reader 内部维护一个缓冲区，每次 ReadString 或 ReadBytes 都会从缓冲中查找换行符，只有缓冲不足时才触发底层文件读取。

按行读取并发送到通道的代码示例如下：

reader := bufio.NewReader(f)
for {
    line, err := reader.ReadString('\n')
    if len(line) > 0 {
        lines <- strings.TrimRight(line, "\n")
    }
    if err == io.EOF {
        time.Sleep(200 * time.Millisecond)
        continue
    }
    if err != nil {
        return
    }
}

这里使用 strings.TrimRight 去掉行尾的换行符，方便后续统一处理。需要注意的是，如果日志行非常长，ReadString 可能会分配较大的缓冲区；如果行长度超过默认缓冲限制，需要在 NewReader 时通过 NewReaderSize 指定更大的 buffer。对于极端情况，也可以改用 ReadSlice 或自定义分隔函数。

当需要同时追踪多个文件时，可以为每个文件启动一个 goroutine，并把读取到的行发送到同一个汇总 channel。主 goroutine 负责消费这些日志行，或者再做过滤、转发。退出机制推荐使用 context.Context，当收到取消信号时通知所有 goroutine 结束。一个简单的 Tailer 结构如下：

type Tailer struct {
    Path   string
    Lines  chan string
    cancel context.CancelFunc
}
func (t *Tailer) Start(ctx context.Context) {
    go func() {
        f, err := os.Open(t.Path)
        if err != nil {
            return
        }
        defer f.Close()
        reader := bufio.NewReader(f)
        for {
            select {
            case <-ctx.Done():
                return
            default:
            }
            line, err := reader.ReadString('\n')
            if len(line) > 0 {
                t.Lines <- strings.TrimRight(line, "\n")
            }
            if err == io.EOF {
                time.Sleep(200 * time.Millisecond)
                continue
            }
            if err != nil {
                return
            }
        }
    }()
}

这个结构还可以继续扩展，例如把 reopenIfRotated 的调用放进循环里，每次读取出现异常或定时检查时重新打开文件；使用 sync.WaitGroup 管理多个 Tailer 的生命周期；或者把 Lines 通道改为带缓冲的 channel，避免消费者处理慢导致写入阻塞影响文件读取。并发追踪虽然能提高吞吐，但也要注意打开文件句柄数量，避免超过系统限制。

容器环境与边界情况思考

在容器化部署中，tail -f 的语义往往被平台日志采集机制替代。Docker 默认会把容器进程的标准输出和标准错误采集到宿主机文件或日志驱动中，Kubernetes 也会通过 kubelet 采集容器日志。如果 Go 程序自身再主动去 tail 某个文件，通常意味着这个文件不是标准输出路径，比如应用同时写了自己的业务日志文件。

这时需要特别关注文件系统的共享行为。容器挂载的卷可能是 overlayfs、NFS 或其他网络文件系统，fsnotify 的事件通知可能不稳定，甚至完全不支持。对于这类场景，建议保留一个低频轮询作为兜底策略，例如每 5 秒检查一次文件大小和 inode，主路径依然依靠事件通知获得低延迟。这样可以兼顾可靠性和实时性。

另外，Windows 与 Linux 在文件共享语义上存在差异，Windows 下文件被其他进程打开时可能不允许删除或重命名，会影响日志轮转。跨平台使用时需要抽象出文件关闭和重新打开的逻辑，并针对不同平台调整错误处理。实际上，很多成熟的日志采集组件都采用“先关闭再重试”的策略来应对文件占用和轮转竞争。