Go文件I/O直白封装系统调用，os.File需显式Close防fd泄漏；os.Open等价于只读OpenFile；大文件须用bufio.Scanner流式处理，os.ReadFile仅适用于小配置文件。
Go 的文件 I/O 不是某种特殊机制，它就是对操作系统“文件描述符”和“字节流”的直白封装——os.File 是句柄，Read 和 Write 是对字节的操作，没有隐藏逻辑，也没有自动编码转换。
为什么 os.Open 和 os.OpenFile 必须配 defer Close()
Go 不会自动回收文件描述符（fd），漏掉 Close() 会导致 fd 泄漏，程序跑久了可能卡在 too many open files 错误上。这不是“建议”，是必须。
-
os.Open("x.txt")等价于os.OpenFile("x.txt", os.O_RDONLY, 0)，只读且要求文件存在 -
os.OpenFile("log.txt", os.O_WRONLY|os.O_CREATE|os.O_APPEND, 0644)才能追加写；少一个 flag（比如漏了O_CREATE）就会报no such file or directory - 哪怕只调一次
Read()或Write()，也得defer f.Close()；函数提前 return 时，defer仍会执行
os.ReadFile vs bufio.Scanner：选错就崩内存
用错读取方式不是功能问题，是资源问题：os.ReadFile 把整个文件读进内存，适合配置文件这类小于几 MB 的内容；大日志、CSV、原始数据文件必须流式处理。
wechat-article-extraction-mp-weixin-qq-com news-webpage-cleaning blog-post-parsing metadata-extraction-title-author-date multiple-output-formats-markdown-json-plain-text batch-processing-support
下载
基于三引擎设计，从微信文章、新闻和博客网页提取干净内容，支持标题作者日期元数据，多格式和批量处理。
-
os.ReadFile("config.json")→ 简洁安全，返回[]byte，Go 1.16+ 推荐，别再用已弃用的ioutil.ReadFile - 逐行处理大文件？用
bufio.Scanner：scanner := bufio.NewScanner(f)，然后for scanner.Scan() { ... }；注意默认单行上限 64KB，超长行会报scanner: token too long，需提前scanner.Buffer(make([]byte, 4096), 1 - 想控制每次读多少字节？用
f.Read(buf)，自己管理buf := make([]byte, 8192)，循环直到err == io.EOF
io.WriteString 和 fmt.Fprintf 写入行为差异
它们都往 io.Writer 写，但语义和开销不同：前者只写字符串，后者支持格式化，但会额外分配临时字符串。
立即学习“go语言免费学习笔记（深入）”；
-
io.WriteString(f, "done\n")最轻量，无格式化开销，适合日志追加、协议头写入 -
fmt.Fprintf(f, "count=%d, name=%s\n", n, name)方便，但每次调用都会做字符串拼接和内存分配；高频写入（如每毫秒一条）建议改用bufio.Writer+io.WriteString组合 - 写完不
Close()可能丢数据；用bufio.Writer时还得多一句w.Flush()，否则缓冲区内容卡在内存里
最常被忽略的不是语法，而是错误检查粒度：file.Read() 返回 n, err，n > 0 时即使 err != nil（比如 io.EOF）也要先处理已读数据；而 scanner.Err() 必须在循环结束后显式检查，否则磁盘 IO 错误会被静默吞掉。
