go中文件流自定义过滤应实现io.reader接口并用bufio.reader+状态机做字节级处理，而非用scanner（行导向与read字节导向冲突导致性能差、不兼容二进制等）。
Go 里对文件流做自定义过滤，核心不是“包装文件”，而是实现 io.Reader 接口，在 Read 方法里嵌入逻辑。直接操作 *os.File 或用 bufio.Scanner 做预处理都容易踩坑——前者绕过缓冲、后者不兼容下游期望字节流的接口（比如 pg.CopyFrom）。
为什么不能直接在 Read 中调用 scanner.Scan()
因为 scanner.Scan() 是行导向的，而 io.Reader.Read(p []byte) 是字节导向的：调用方传入的 p 大小不固定，可能跨多行、也可能只读半行。如果每次 Read 都强制扫一行，会导致：
-
Read返回字节数远小于len(p)，触发上游反复重试，性能暴跌 - 无法处理二进制数据或含
\n的非文本内容 - 内部状态（如当前扫描位置）和外部
p缓冲区错位，出现漏字节或重复字节
正确做法：用 bufio.Reader + 状态机做字节级过滤
用 bufio.Reader 替代 bufio.Scanner，它提供 ReadByte、Peek、Discard 等底层能力，能精确控制读取节奏。关键是要维护一个内部状态机，比如跳过注释行时：
- 状态 =
inComment：遇到#后持续丢弃直到换行 - 状态 =
inLine：正常拷贝字节，但遇到#就切到inComment - 每次
Read(p []byte)中循环处理，直到填满p或 EOF
示例片段（跳过以 # 开头的整行）：
func (fr *FilteredReader) Read(p []byte) (n int, err error) {
for n
<h3>调试时最容易忽略的三个点</h3>
<p>实际调试中，90% 的流过滤 bug 都出在这三处：</p>
-
io.Reader要求严格遵循“返回n 即表示本次读取结束”，不能因为“还没处理完逻辑”就卡住不返回——否则 <code>http.Request.Body或pg.CopyFrom会永远等待 - 错误处理必须区分
io.EOF和其他err：前者是合法终止信号，后者要透传，不能吞掉 - 内部缓冲区（如用于暂存未完成行的
buf []byte）必须用append动态扩容，不能固定长度——否则大字段或超长行直接截断
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
