路径错误是最常见原因，ioutil.ReadFile不补全相对路径；权限问题、文件独占、大小写敏感、跨设备写入、忽略error返回值及Go 1.16后弃用均为典型陷阱。
用 ioutil.ReadFile 读文件时为什么总报 “no such file or directory”？
路径没写对是最常见原因，ioutil.ReadFile 不会自动补全相对路径，它严格按你传入的字符串去找。比如当前在 /home/user/project 下运行程序，而文件在 ./data/config.json，那必须传 "./data/config.json"，不能只写 "data/config.json"（某些 shell 环境下看似能通，但 Go 运行时不认）。
另一个易错点是权限：Windows 上路径大小写不敏感，Linux/macOS 敏感；如果文件被其他进程独占打开（如 Excel 正在编辑 .csv），ioutil.ReadFile 也会失败，错误信息仍是 "permission denied" 而非更明确的提示。
- 优先用绝对路径调试，确认逻辑正确后再切回相对路径
- 检查文件是否存在：
os.Stat("path")比直接读更早暴露路径问题 -
ioutil.ReadFile会把整个文件加载进内存，别用它读 GB 级日志——改用bufio.Scanner或io.Copy
ioutil.WriteFile 写入失败却没报错？
这通常是因为你忽略了返回值。Go 的惯用法是「必须显式处理 error」，但新手常写成 ioutil.WriteFile("a.txt", data, 0644)，没接 error，导致失败静默发生。
还有两个隐蔽坑：0644 是 Unix 权限掩码，Windows 上会被忽略，但若父目录不可写（比如 /usr/local/），写入仍失败；另外，ioutil.WriteFile 是原子操作：先写临时文件再 rename，如果目标路径跨磁盘（如从 /tmp 写到 /mnt/usb），rename 会失败并返回 "invalid cross-device link"。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 永远检查 error：
err := ioutil.WriteFile(...); if err != nil { ... } - 确保父目录存在且可写，可用
os.MkdirAll(filepath.Dir(path), 0755)预创建 - 跨设备写入场景下，改用
os.Create+io.WriteString绕过 rename
为什么官方文档说 ioutil 已弃用？
从 Go 1.16 开始，ioutil 包被拆进 io 和 os：比如 ioutil.ReadFile 移到了 os.ReadFile，ioutil.WriteFile 移到了 os.WriteFile。这不是“不能用”，而是标准库收敛接口、减少包依赖的常规演进。
区别很小：新函数签名完全一致，行为一模一样，只是包路径变了。但如果你用的是 Go ioutil，go vet 会警告，且未来版本可能彻底删除。
- 升级 Go 后，批量替换：
s/"ioutil"/"os"/g即可 - 旧项目维持
ioutil也能跑，但建议尽早切换，避免后续兼容问题 -
os.ReadFile底层仍调用os.Open+readAll，性能无差异
大文件分块读写该用哪个 API？
os.ReadFile 和 os.WriteFile 是为小配置、JSON、模板等短内容设计的。一旦文件超过几十 MB，内存占用和 GC 压力会明显上升，这时候必须换流式处理。
核心选择就两个：os.Open + bufio.Reader 适合按行或按块读；os.Create + bufio.Writer 适合缓冲写入。不要自己搞 make([]byte, 4096) 循环 read，bufio 已优化好边界和扩容逻辑。
- 读大日志：用
scanner := bufio.NewScanner(f); for scanner.Scan() { line := scanner.Text() } - 写大导出数据：用
w := bufio.NewWriter(f); w.WriteString(...); w.Flush() - 二进制流（如图片复制）：直接
io.Copy(dst, src)，它内部自动用 32KB 缓冲区
os.ReadFile 和 os.WriteFile 覆盖 80% 的小文件场景，但只要涉及路径动态拼接、跨平台部署、或文件体积不确定，就得立刻跳出这个舒适区，去碰 os.Open 和 io 接口——不是因为它们更“高级”，而是更可控。 
