Golang 中文件读取报错处理的防御性编程

文件操作在Go里看似简单，但稍有不慎就会埋下隐患。忽略os.Open的err检查可能导致程序直接panic；读取大文件时不限制大小可能触发OOM；写入后不校验实际字节数，数据可能在不知不觉中被截断；处理符号链接时如果用错了函数，还可能引发安全漏洞。这些都不是理论问题，而是在生产环境中真实发生的“事故”。

os.Open 后不检查 err 导致 panic

很多开发者以为os.Open返回的*os.File在错误时为nil，因此只做空指针检查。但Go的os.Open有一个让人意外的行为：即使返回了错误，返回的*os.File也可能不是nil——在某些部分成功的系统调用下，文件句柄虽然存在但已经失效。这时候对它的任何操作都会导致确定性的panic。

• 永远用if err != nil判断，而不是if file == nil。
• defer file.Close()必须放在err == nil的分支内，否则错误路径上调用Close()同样会panic。
• 需要区分错误类型时，优先用errors.Is(err, os.ErrNotExist)或os.IsPermission(err)，而非字符串匹配。

ReadAll() 在大文件上触发 OOM

io.ReadAll()（替代已弃用的ioutil.ReadAll()）会把整个文件加载进内存，对超过10MB的文件极易被系统kill。这不是“性能差”，而是资源失控风险。

• 先用os.Stat().Size()检查文件大小，超阈值（如10MB）直接拒绝或走流式路径。
• 读取配置/日志等文本文件，用bufio.Scanner按行处理，避免一次性加载。
• 二进制或不确定大小的文件，用io.CopyN(dst, src, n)或循环调用file.Read(buf)分块读取。
• io.ReadAll()返回的[]byte和原*os.File无绑定关系，Close()不影响已读数据，但别指望它自动释放底层fd。

Write() 后忽略 n 值引发数据截断

Write()和WriteString()都返回(int, error)，其中int是实际写入字节数。网络文件系统（NFS）、磁盘满、信号中断等场景下，error可能为nil，但n小于预期长度——这是合法行为，不是bug。

• 不要只判err != nil，必须校验n == len(data)。
• 简单场景用io.WriteString(file, s)替代file.WriteString(s)，前者内部已做补全。
• 关键写入（如日志、事务记录）建议调用file.Sync()确保落盘，但注意它会阻塞并增加延迟。
• 批量写入时，用bufio.NewWriter(file)提升吞吐，但记得最后调用wr.Flush()，否则缓冲区内容丢失。

符号链接处理不当导致越权或死循环

用os.Stat()代替os.Lstat()会自动解析符号链接，可能跳转到任意路径（如/etc/passwd），造成越权访问；手动递归遍历时若不检测循环引用，filepath.EvalSymlinks()可能卡住或返回too many levels of symbolic links。

• 判断是否为软链接，必须用os.Lstat()，它只读取路径自身元数据。
• 需要解析真实路径时，用filepath.EvalSymlinks()，但之后必须用strings.HasPrefix(realPath, allowedBase)校验是否在可信目录内。
• 坏链（dangling symlink）既不是有效文件也不是安全链接，os.Lstat()能看见它，os.Stat()和EvalSymlinks()都失败，这个中间态需显式处理。
• 自定义目录遍历逻辑中，需维护已访问路径集合，防止循环引用。

真正的防御从来不是事后加异常捕获，而是在每一步操作之前就想清楚：路径是否可信？文件大小是否可控？写入是否完整？链接是否越界？Go的error是一种契约，不是负担。忽略它，就等于把控制权拱手让给操作系统的随机调度。