go文件操作需四步防御：先filepath.clean归一化路径，再strings.hasprefix校验白名单前缀（结尾带斜杠），接着os.lstat检测符号链接（mode()&os.modesymlink!=0），最后os.openfile配os.o_nofollow打开。
Go 的文件操作天生不健壮，os.Open、os.ReadFile 等函数只做最基础的系统调用封装，不校验路径合法性、不防范符号链接、不检查权限、不处理中断或磁盘满——生产环境出问题不是“如果”，而是“何时”。
路径安全与符号链接怎么防？
用户传入的路径（比如 filename=../../etc/passwd）若不清洗，filepath.Clean 之后仍可能越界；直接 os.Open 会打开真实目标，而非你预期的子目录。
- 永远先调
filepath.Clean，再检查是否以允许前缀开头（如strings.HasPrefix(cleaned, "/var/data/")） - 用
os.Lstat（非os.Stat）获取元信息：它不跟随符号链接，能区分fi.Mode()&os.ModeSymlink != 0 - 若需读取目标文件，再用
os.Open，但必须确认fi.Mode().IsRegular()且!fi.Mode().IsDir() - 避免
os.Readlink后手动解析——循环链接、跨挂载点等边界 case 极难覆盖，直接拒绝符号链接更安全
os.Open 失败后 defer file.Close() 为什么会 panic？
os.Open 返回 file *os.File, err error，失败时 file == nil。若写成 defer file.Close()，程序会在 nil 上调用方法，触发 panic: runtime error: invalid memory address。
- 正确写法是：先判
err，再defer file.Close()，绝不能放在os.Open后无条件执行 - 若逻辑分支多（如 fallback 到临时路径），建议把
file声明为局部变量并初始化为nil，Close 前加if file != nil - 更稳妥的做法：封装一个带错误检查的打开函数，返回
io.Closer接口，统一管理生命周期
大文件读取时 ioutil.ReadFile 已弃用，但 os.ReadFile 还会 OOM 吗？
会。os.ReadFile（Go 1.16+ 替代 ioutil.ReadFile）仍是全量加载进内存，对几百 MB 日志或上传文件极易触发 GC 压力甚至 OOM。
- 顺序读：用
os.Open+bufio.Scanner，但注意默认MaxScanTokenSize = 64KB，超长行报scanner: token too long；可设scanner.Buffer(make([]byte, 1MB), 1MB) - 结构化数据（如每行 JSON）：优先用
json.NewDecoder(file)直接流式解码，不走[]byte中转 - 二进制或固定格式大文件：预分配切片 +
io.ReadFull(file, buf)，避免bufio.Scanner的动态扩容和 GC 开销
写文件如何避免崩溃丢数据或残留脏文件？
直接 os.Create 写目标路径，进程崩溃或断电会导致文件内容损坏或写到一半就终止——没有原子性保证。
- 标准做法：用
os.CreateTemp("", "prefix-*.tmp")创建临时文件，写完后调os.Rename(tmp, target) -
Rename在 Unix/Linux/macOS 下是原子操作；Windows 要求同磁盘，否则返回syscall.EXDEV，此时需 fallback 到io.Copy+os.Remove - 写临时文件前，用
os.Chmod(tmpFile, 0600)设权限，防止其他用户在写入中途读取敏感内容 - 关键：所有写操作后必须显式
tmpFile.Sync()（尤其关键日志），再tmpFile.Close()，最后Rename—— 缺一环都可能丢数据
健壮性的核心不是“封装得漂亮”，而是每一步都预设它会失败：路径非法、磁盘满、权限不足、系统调用被信号中断（syscall.EINTR）、NFS 挂载点突然不可用……这些不是边缘 case，而是生产环境的日常。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
