os.create默认权限0666受umask影响，应改用os.openfile显式指定权限（如0644）；读写需正确组合flag（o_create/o_trunc/o_append等）；小文件用os.readfile，大文件分块读；defer file.close()须在非nil后调用。
os.Create 创建文件时权限不对，新文件没法写入
Linux/macOS 下 os.Create 默认用 0666 权限，但会受 umask 影响，实际可能变成 0644 或更严格——这本身没问题，但如果你在容器或 CI 环境里跑，umask 是 0022 或 0002，就容易误以为“文件创建失败”，其实只是没写权限。别急着加 chmod，先确认是不是这个原因。
真正该做的是：显式传入需要的权限位，比如可执行脚本要 0755，纯数据文件用 0644：
file, err := os.OpenFile("config.json", os.O_CREATE|os.O_WRONLY, 0644)
注意：os.Create 内部就是调的 os.OpenFile + 0666，它不接受权限参数，所以别硬套 os.Create("x.txt", 0644) —— 这会编译报错。
-
os.Create没有权限参数，强行加会报too many arguments - 想控制权限，必须用
os.OpenFile，搭配os.O_CREATE | os.O_TRUNC | os.O_WRONLY - Windows 忽略权限位，但代码跨平台时仍建议统一写
0644，Go 会自动忽略
os.Open 和 os.OpenFile 区别搞混，读写模式开错
os.Open 只能读，等价于 os.OpenFile(path, os.O_RDONLY, 0)；而 os.OpenFile 是万能入口，但新手常把 flag 写错，比如想追加却用了 os.O_WRONLY，结果覆盖原内容。
立即学习“go语言免费学习笔记（深入）”；
常见组合记牢就行：
- 只读：用
os.Open("x.log")，最简、最安全 - 只写（覆盖）：
os.OpenFile("x.log", os.O_WRONLY|os.O_CREATE|os.O_TRUNC, 0644) - 追加写：
os.OpenFile("x.log", os.O_WRONLY|os.O_CREATE|os.O_APPEND, 0644) - 读写（不截断）：
os.OpenFile("x.log", os.O_RDWR|os.O_CREATE, 0644)
漏掉 os.O_CREATE 会导致文件不存在时报 no such file or directory；漏掉 os.O_TRUNC 会导致写入时从头覆盖——这两个错误现象背后往往就是 flag 拼错了。
Android文件存取与数据库编程知识，文件操作主要是读文件、写文件、读取静态文件等，同时还介绍了创建添加文件内容并保存，打开文件并显示内容；数据库编程方面主要介绍了SQLite数据库的使用、包括创建、删除、打开数据库、非查询SQL操作指令、查询SQL指令-游标Cursors等知识。
读取小文件用 ioutil.ReadFile 就够了，别一上来就 bufio.Scanner
Go 1.16+ 已把 ioutil.ReadFile 移到 os.ReadFile，它内部做了优化：对小于 32KB 的文件直接 syscall.Read，不用额外 buffer。你不需要自己开 os.Open + io.ReadAll，除非要控制内存上限或处理超大文件。
但要注意：如果文件可能大于几十 MB，os.ReadFile 会一次性把全部内容 load 到内存，可能 OOM。这时候才轮到 bufio.Scanner 或 bufio.Reader 分块读。
- 配置文件、JSON、YAML 等小文本，直接
os.ReadFile("config.yaml") - 日志文件、导出数据等大文件，用
os.Open+bufio.NewReader+ReadString('\n')或ReadBytes('\n') -
bufio.Scanner默认单行上限 64KB，超长行会报scanner: token too long，得提前设ScanLines或换ReadBytes
defer file.Close() 忘写，或者写在错误分支外导致 panic
最常见的资源泄漏不是忘记关，而是 defer 放错位置。比如：
file, err := os.Open("x.txt")<br>if err != nil {<br> return err<br>}<br>defer file.Close() // ✅ 正确：file 已确定非 nil
但如果写成这样就危险：
var file *os.File<br>if condition {<br> file, _ = os.Open("x.txt")<br>}<br>defer file.Close() // ❌ panic: close of nil pointer
还有种隐蔽情况：函数里多次 os.Open，但只 defer 一个，另一个忘了关。
- 每个成功打开的
*os.File都要配一个defer xxx.Close() - 别 defer 可能为
nil的变量；先判 err，再 defer - 用
errgroup或sync.WaitGroup并发开文件时，close 必须和 open 在同一个 goroutine 里
文件描述符耗尽不是玄学，是真实会发生的事，尤其在长期运行的服务里。查 lsof -p PID | wc -l 超过几千就得警惕了。
