os.ReadFile仅适用于≤5MB小文件，如配置文件、JSON模板等；因其一次性全量加载内存，读大文件会静默OOM或被系统kill，不支持流控、中断或跳过。
os.ReadFile 不能封装成“通用读取函数”——它只适用于 ≤5MB 的小文件，强行用于大文件会静默 OOM，这不是封装能绕开的底层限制。
什么时候该用 os.ReadFile？
仅当你能**静态确认文件大小可控**时才用它，比如读取本地配置、嵌入模板、短 JSON 片段。
- 它内部自动调用
os.Open→io.ReadAll→file.Close，省事但无流控 - 返回
[]byte，不支持跳过、中断、按需解码 - 错误只反映路径/权限问题，内存耗尽不会报
error，而是被系统 kill 或卡死 - 别把它和
bufio.Scanner混用——前者是全量加载，后者是流式切分，语义冲突
读大文本文件（如日志、CSV）必须用 bufio.Scanner
这是 Go 官方推荐的按行处理方式，内存恒定、逻辑清晰、默认适配换行边界。
- 初始化后调用
scanner.Scan()，每次只拉一行进内存 - 默认缓冲区 4KB，单行超 64KB 会报
scanner.ErrTooLong，需提前调用scanner.Buffer(make([]byte, 0, 1 扩容 - 不要在循环里反复
make([]byte, ...)，scanner.Text()返回的是内部 buffer 的切片，复用安全 - 若需保留原始字节（比如含空字符），改用
scanner.Bytes()，避免 string 转码开销
读二进制或非结构化大文件要用 io.Copy 或手动 Read 循环
比如复制 ZIP、上传分块、解析协议头等场景，核心是控制每次搬运的字节数，而非按行。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
-
io.Copy(dst, src)是首选：内置 32KB 缓冲，自动识别io.ReaderFrom/io.WriterTo实现，可能触发零拷贝路径 - 手动循环必须显式检查
err == io.EOF才退出，漏判会导致 panic 或重复写空数据 - 缓冲区大小建议设为 64KB（
64 * 1024）：太小增加 syscall 频次，太大加重 GC 压力，尤其在高并发混合读取时 - 别用
make([]byte, 0, huge)预分配传给Read——bufio.Reader自己管理缓冲，外部 slice 只是读出目标
封装函数前先想清楚：你到底要什么语义？
所谓“封装”，不是套个函数名就完事。真正容易踩坑的是混淆不同 IO 模型的适用边界：
- 想“读一个配置” → 直接用
os.ReadFile，加个 size check 就够了 - 想“逐行处理日志” → 封装成接收
io.Reader+ callback 函数，内部用bufio.Scanner - 想“流式转发 HTTP body 到磁盘” → 封装成
func(src io.Reader, dst *os.File) error，直接调io.Copy - 想“读固定 header 后跳过剩余内容” → 必须用
io.LimitReader包裹原始*os.File，再用binary.Read解析
最常被忽略的一点：文件句柄生命周期和错误传播路径。用 defer file.Close() 很方便，但一旦封装进工具函数，就得明确谁负责关、关失败是否要透出——很多“封装”最后变成资源泄漏黑盒。
