最稳妥方案是goroutine+sync.waitgroup+带缓冲channel；需控制并发数、显式传参、及时关文件，避免循环变量捕获错误和fd耗尽。
直接上结论：用 goroutine + sync.WaitGroup + 带缓冲 channel 是最稳妥、可落地的方案；但别无脑开 goroutine，得控制并发数、显式传参、及时关文件。
为什么不能直接 for-range + go func() { os.ReadFile }？
这是新手最常踩的坑：循环变量捕获错误。所有 goroutine 最终读的都是最后一个 path 值，而不是各自对应的文件路径。
- 错误写法：
for _, path := range paths { go func() { os.ReadFile(path) }() } - 正确做法：必须把
path显式作为参数传入闭包：go func(p string) { os.ReadFile(p) }(path) - 不加参数就 defer
f.Close()也没用——文件句柄早被覆盖或 nil，defer只是延迟执行一个空操作
如何安全并发读取多个 YAML/JSON 配置文件？
配置文件通常不大（KB～MB 级），但数量可能几十上百。重点不是吞吐，而是不出错、不泄漏、能统一收结果。
- 每个 goroutine 单独调用
os.Open→yaml.Unmarshal或json.Unmarshal→defer f.Close() - 用带缓冲的
resultChan := make(chan ConfigResult, len(paths))收集结果，避免阻塞或死锁 - 不要用无缓冲 channel 配大量 goroutine，尤其当某文件解析失败卡住时，整个流程会 hang
- 示例结构：
type ConfigResult { Name string Data map[string]interface{} Err error }
并发数该设多少？
不是越多越好。配置文件读取本质是磁盘 I/O + CPU 解析，盲目开 100 个 goroutine 可能导致 fd 耗尽、系统调度开销反超收益。
- 一般建议：5～20 个 worker 够用（取决于文件数量和平均大小）
- 更稳的做法：用带缓冲的 job channel 控制并发度，比如
jobs := make(chan string, 10)，再启固定数量 worker 从 channel 拉任务 - 注意：Linux 默认单进程最多打开 1024 个文件，
ulimit -n查看，超了会报too many open files - 如果配置文件来自网络（如 etcd、Apollo），还要加
context.WithTimeout防止某个请求拖垮整体
要不要用 Viper 并发加载？
别这么做。viper.ReadInConfig() 内部不是线程安全的，且它本身已封装了文件读取+解析逻辑，强行并发调用容易触发竞态或 panic。
- 正确姿势：用原生
os.ReadFile+yaml.Unmarshal等组合，自己控制并发 - Viper 更适合单实例、单配置源的场景；多配置文件并行加载，绕过它更干净、可控
- 若必须用 Viper，只在每个 goroutine 里初始化独立的
viper.Viper实例，别共享全局viper
真正麻烦的从来不是“怎么并发”，而是“并发之后谁负责关文件、谁汇总错误、谁决定重试”。这些细节没对齐，再多 goroutine 也白搭。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
