必须调用Close()才能确保文件内容刷入磁盘、避免句柄泄漏；os.Create无缓冲，小量高频写应使用bufio.NewWriter；其默认覆写且权限受umask影响，需显式控制；Write和Close均需检查error。
os.Create 写入文件前必须调用 Close()
直接用 os.Create 得到的 *os.File 是一个打开的文件句柄，不手动 Close() 会导致文件内容可能未刷入磁盘、句柄泄漏，甚至在 Windows 上后续无法再次打开该文件。常见错误是只写不关，或 defer 放错位置（比如放在函数开头但中间 panic 了却没执行）。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 始终配对使用
defer f.Close()，且放在os.Create成功之后立即写 - 如果需要判断写入是否成功，
Close()本身也会返回 error —— 它会触发底层 flush，很多“写入失败”其实是在Close()时才暴露 - 不要依赖 GC 自动关闭：Go 不保证何时回收，也不保证会调用
Close()
Write 和 WriteString 的行为差异与缓冲问题
os.File 没有内置缓冲，Write() 和 WriteString() 都是直接系统调用（syscall.Write）。这意味着每次调用都可能触发一次内核态切换，小数据高频写入性能差，且无法保证原子性（比如写一半崩溃，文件就残缺）。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 单次写入量小（如日志行、配置项）时，优先用
bufio.NewWriter(f)包一层，再调用WriteString()+Flush() - 若必须用原生
Write()，注意它返回已写字节数，要检查是否等于预期长度，否则属于部分写入（尤其在磁盘满或中断时） -
WriteString()底层仍转成[]byte，无性能优势，纯为方便；二者错误类型一致，都返回int和error
os.Create 覆盖行为与权限控制陷阱
os.Create 等价于 os.OpenFile(name, os.O_CREATE|os.O_TRUNC|os.O_WRONLY, 0666)，意味着：文件存在就清空重写，不存在则新建；但第三个参数 0666 是传给操作系统 umask 过滤后的权限，实际创建权限通常是 0666 &^ umask（Linux 默认 umask=0022 → 实际为 0644）。
常见错误现象：
- 在某些容器或 CI 环境中 umask 被设为 0077，导致文件变成 0600，其他用户/进程无法读取
- 误以为
os.Create会保留原文件权限（它不会，总是用固定 mode） - 想追加写入却用了
os.Create，结果把旧内容全删了
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 需要精确权限控制，改用
os.OpenFile显式传入所需mode，例如0644 - 想追加写入，用
os.OpenFile(name, os.O_CREATE|os.O_APPEND|os.O_WRONLY, 0644) - 写入前确认父目录存在，
os.Create不会自动创建多级路径，需提前os.MkdirAll
错误处理不能只看 Create，Write 和 Close 都要检查
很多人只检查 os.Create 返回的 error，却忽略 Write() 和 Close() 的返回值。典型场景：磁盘已满，Create 成功（因为只是创建空文件），Write() 可能返回 short write 或 no space left on device，而 Close() 才真正把缓冲区数据落盘，此时才暴露出写入失败。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 每一步都做 error 检查，或至少把
Write()和Close()的 error 合并处理 - 推荐模式：
err := f.Close() if err != nil { return err // 或 log.Fatal } - 如果业务要求强一致性（如配置文件写入后必须生效），应在
Close()成功后再进行后续操作（如 reload）
Close() 才是真正落盘的临门一脚。 
