os.mkdirall是创建嵌套路径的唯一可靠方式，它递归创建所有缺失父目录、已存在时静默返回nil，需配合filepath.dir提取父路径、用0755而非755设权限，并发调用须加锁防竞态。
os.MkdirAll 是创建嵌套路径的唯一可靠方式
直接调用 os.Create 或 os.OpenFile 写入一个带多级子路径的文件（比如 "logs/error/2024/06/app.log"），一定会报 no such file or directory 错误——Go 不会自动补全父目录。你必须先确保路径存在。
os.MkdirAll 就是为此设计的：它递归创建所有缺失的父目录，且对已存在路径静默返回 nil，不引入 TOCTOU 竞态。别用 os.Stat + os.Mkdir 组合判断再创建，那是典型竞态陷阱。
- 正确写法：
err := os.MkdirAll(filepath.Dir("/tmp/a/b/c/file.txt"), 0755) - 务必配合
filepath.Dir提取父目录，而不是硬编码路径字符串 - 权限参数传
0755而非755（后者是十进制，实际权限会错乱）
权限 0755 在 Windows 和 Unix 上表现一致吗
行为目标一致，但底层生效逻辑不同：Linux/macOS 上，0755 会与进程 umask 按位取反后生效（例如 umask=0022 → 实际得 0755）；Windows 则忽略执行位，只保留读写控制，0755 和 0644 效果几乎相同。
所以统一用 0755 是安全选择：它在 Unix 上保证目录可遍历（x 位必需），其他用户不可写；在 Windows 上也足够表达“可读写”意图，且不会因平台差异导致意外开放权限。
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
- 不要传
os.ModePerm（即0777），它在 umask 严格环境下反而更不开放 - 生产环境避免依赖系统默认 umask，显式传
0755更可控 - 如果真需校验创建后的权限是否符合预期，得额外调用
os.Stat+fi.Mode()
并发调用 os.MkdirAll 会出问题吗
会。多个 goroutine 同时调用 os.MkdirAll("a/b/c", 0755) 可能触发重复系统调用、中间目录权限被覆盖，甚至返回 os.ErrExist 或 os.IsPermission 类错误——这不是 Go 的 bug，而是底层 mkdir 系统调用本身不具备原子性。
若你的初始化逻辑可能被并发触发（比如 HTTP handler 初始化日志目录），应加锁或使用 sync.Once 包裹，而不是指望 os.MkdirAll 自动解决竞态。
- 简单场景可用
sync.Once：定义全局var initDir sync.Once，然后initDir.Do(func() { os.MkdirAll(...) }) - 高并发服务中，建议在程序启动阶段集中初始化所有目录，而非按需懒创建
- 不要依赖
os.IsExist(err)来“吞掉”并发冲突错误——它只表示路径已存在，不表示创建成功或权限正确
为什么 os.Mkdir 创建多级路径一定失败
os.Mkdir 只负责创建最末一级目录，要求其所有父目录必须已存在。比如 os.Mkdir("a/b/c", 0755)，只要 "a" 或 "a/b" 缺失，就立刻报错 no such file or directory。
它适合明确知道父目录已就绪的场景（如容器内固定挂载点），但绝大多数应用初始化逻辑都不满足这个前提。一旦误用，错误堆栈里只会看到路径不存在，而不会提示“你应该用 os.MkdirAll”。
- 常见误用：把
os.Mkdir当成mkdir -p用 - 调试时看到
stat a/b/c: no such file or directory，第一反应不是路径写错，而是该换os.MkdirAll -
os.Mkdir对已存在目录返回os.ErrExist，需手动用os.IsExist判断并跳过，不如os.MkdirAll省心
os.MkdirAll 很容易变成“看似工作、实则埋雷”的操作。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
