os.Open仅读已存文件，失败则报错；os.Create覆盖写或新建文件，清空内容；二者语义、权限、行为不同，混用致数据丢失或权限拒绝。
os.Open 只能读已有文件，os.Create 会清空或新建可写文件——二者语义、权限、行为完全不同，混用会导致数据丢失或权限拒绝。
os.Open：只读打开，文件必须存在
它调用底层 os.OpenFile(name, os.O_RDONLY, 0)，仅允许读取。如果文件不存在，返回 *os.PathError（错误信息含 "no such file or directory"）；即使有写权限，file.Write 也会报 bad file descriptor。
- 适用场景：读配置、日志、静态资源等“只看不改”的文件
- 常见错误：用
os.Open尝试写入，panic 或静默失败 - 注意：不会创建父目录，路径中任一上级目录缺失即报错
os.Create：覆盖写入，隐含 O_TRUNC + O_CREATE
os.Create("a.txt") 等价于 os.OpenFile("a.txt", os.O_RDWR|os.O_CREATE|os.O_TRUNC, 0666)。这意味着：
- 若
a.txt已存在 → 内容被清空，句柄可读可写 - 若
a.txt不存在 → 创建新文件，权限为0666 &^ umask（通常为0644） - 若
a.txt的父目录（如logs/）不存在 → 直接报错，不自动创建
⚠️ 容易踩的坑：os.Create 不是“安全追加”，它永远先清空——想保留旧内容必须用 os.OpenFile(..., os.O_APPEND|os.O_CREATE|os.O_WRONLY, 0644)。
立即学习“go语言免费学习笔记（深入）”；
何时该用 os.OpenFile 而不是 Open/Create
当需求超出两个函数的默认组合时，必须上 os.OpenFile。它才是真正的“底层开关”，所有标志位（os.O_APPEND、os.O_EXCL、os.O_SYNC 等）都靠它控制。
- 追加日志：用
os.OpenFile("log.txt", os.O_APPEND|os.O_CREATE|os.O_WRONLY, 0644) - 原子写入（防止中断损坏）：加
os.O_EXCL | os.O_CREATE确保文件全新 - 只读但允许 symlinks：需额外 flag（
os.OpenFile支持，os.Open不暴露） - 权限敏感场景：
0600（仅属主读写）比默认0666更安全
一个小而关键的实践细节：defer Close 的时机
os.Open 和 os.Create 都返回 *os.File，必须显式 Close()。但注意：
- 如果在循环中反复
os.Create同名文件，前一个file未Close()就被新值覆盖 → 文件句柄泄漏（尤其 Windows 下可能报 “too many open files”） -
defer file.Close()在函数 return 前执行，但如果函数里有多次 open/create，要确保每个file都有对应defer，或用 block scope 控制生命周期
真正容易被忽略的是：Go 不会自动回收未关闭的 *os.File，哪怕变量已出作用域——这和内存 GC 无关，是操作系统级资源。
