os.ReadFile适合读取≤几MB的静态小文件，如配置、JSON、YAML等，自动管理文件资源；大文件或需逐行处理时应选bufio.Scanner或bufio.Reader，避免OOM和panic。
小文件直接用 os.ReadFile，大文件或需逐行处理时必须用 bufio.Scanner 或 bufio.Reader，否则容易 OOM 或 panic。
什么时候该用 os.ReadFile？
它适合读取 ≤几 MB 的配置、JSON、YAML、模板等静态小文件。内部自动 Open → 读取 → Close，不手动管理资源，也不用担心漏关文件描述符。
- 函数签名是
os.ReadFile(filename string) ([]byte, error)，返回原始字节切片，转字符串只需string(data) - 不处理编码：UTF-8 没问题；GBK/Shift-JIS 等需用
golang.org/x/text/encoding转换，否则中文变??? - 错误检查不能省——比如文件权限不足时返回
permission denied，路径错则报no such file or directory - 别在日志分析、CSV 导入等场景硬套它：100MB 日志文件会直接吃光内存，且没提供任何流控能力
为什么 bufio.Scanner 是文本类大文件的首选？
它专为“人类可读文本”设计，自动按行切分、剥离换行符，内存占用稳定（默认缓冲区仅 64KB），适合日志解析、CSV 行处理、配置片段提取等。
- 必须配
defer f.Close()，os.Open返回的*os.File不会自动关闭 - 单行超长（>64KB）会触发
scanner: token too long错误；修复方式：调用scanner.Buffer(make([]byte, 0), 1 扩容到 1MB -
scanner.Text()返回的是不含\n的字符串，若需保留换行或处理空字节，请换bufio.Reader - 别在循环里忽略
scanner.Err()—— 文件中途被删、磁盘满等错误只在这里暴露，漏判会导致静默失败
遇到二进制、超长行或自定义分隔符怎么办？
这时候 bufio.Scanner 就不够用了。bufio.Reader 提供更底层控制：可指定分隔符、读固定长度、支持 peek、兼容空字节，是处理协议文件、打包格式、日志归档等场景的可靠选择。
移动端无限滚动加载瀑布流
下载
里面有2个文件夹。其中这个文件名是:finishing，是我项目还没有请求后台的数据的模拟写法。请求后台数据之后，瀑布流的js有一点点变化，放在文件名是：finished。变化在于需要穿参数到后台，和填充的内容都用后台的数据填充。看自己项目需求来。由于chrome模拟器是不允许读取本地文件json的，所以如果你要进行测试，在hbuilder打开项目就可以看到效果啦，或者是火狐浏览器。
立即学习“go语言免费学习笔记（深入）”；
- 用
reader.ReadString('\n')或reader.ReadBytes('\0')替代Scan()，避免单行限制 - 读取固定头信息（如 PNG 文件头 8 字节）推荐
io.ReadFull(reader, headerBuf)，它确保读满，不会因 EOF 提前返回 - 若要边读边解密/校验/压缩，直接拿
*os.File当io.Reader传给crypto/aes或hash/crc32，比先读进内存再处理更安全 - 注意：所有
Read*方法都可能只读部分数据，必须检查返回的n和err，io.EOF是正常结束信号，其他err需中断流程
真正容易出事的不是选错函数，而是把 os.ReadFile 当万能锤去读日志，或者在 Scanner 里忘了扩容缓冲区导致线上 panic；还有人用 fmt.Fscanf 解析 CSV，结果字段含逗号就全乱了——工具本身没错，错在没看清它的适用边界。
