最稳妥方案是用sync.Semaphore（Go 1.21+）或golang.org/x/sync/semaphore，因其支持上下文取消、panic安全释放；chan struct{}易漏释放致永久阻塞，且len(sem)返回已占用数而非可用数，不可靠。
直接用 sync.Semaphore（Go 1.21+）或 golang.org/x/sync/semaphore 控制文件处理并发数最稳妥，chan struct{} 手写信号量容易在 panic 或错误分支里漏释放，导致后续所有任务永久阻塞。
为什么不能用 len(sem) 判断是否能进
常见误解是拿 len(sem) 当“剩余空位数”来判断是否可启动新任务——它返回的是当前已占用的槽位数，不是可用数。真正可用数是 cap(sem) - len(sem)，但这个值在多 goroutine 竞争下瞬时失效，无法作为安全依据。
-
len()是快照值，不带原子性，不能用于决策逻辑 - 哪怕你看到
len(sem) == 0，下一毫秒就可能被其他 goroutine 占满 - 正确做法永远是直接调用
Acquire或往chan发送，依赖阻塞机制本身做协调
sync.Semaphore 初始化和使用必须配对检查 error + defer release
Go 1.21+ 标准库的 sync.Semaphore 不是简单计数器，它要求显式处理上下文取消和 panic 安全释放。
- 初始化必须传
int64：比如限 8 并发，得写semaphore.NewWeighted(8)，传8（int）会编译失败 -
sem.Acquire(ctx, 1)必须检查返回error：若 ctx 已超时或取消，会返回context.DeadlineExceeded或context.Canceled，此时不能继续读文件 -
defer sem.Release(1)要写在 goroutine 最外层函数开头，确保即使os.Openpanic 或io.Copy失败也能归还许可
文件上传/下载并发控制的关键位置在 os.Open 前、io.Copy 后
限流逻辑放错位置等于没限——很多人把信号量放在 goroutine 启动前或 for 循环外，结果只是减慢了任务派发速度，实际打开的文件句柄数仍超标。
立即学习“go语言免费学习笔记（深入）”；
- 正确位置：
sem.Acquire(ctx, 1)在os.Open之前；defer sem.Release(1)在函数入口注册，覆盖整个处理流程 - 错误示范：
for range files { go func() { sem.Acquire(...) }—— 这里sem在循环外，只控启动节奏，不控实际打开数 - 流式大文件尤其要注意：不要等
io.Copy完才释放，必须在 goroutine 结束时释放，否则长耗时传输会一直占着 slot
http.Transport 的连接池参数 ≠ 文件并发数，别混用
如果你在处理的是 HTTP 文件下载（比如从远端 URL 下载），常有人误以为调大 MaxConnsPerHost 就能提升并发——它只管复用连接池，和你开多少 goroutine 去读文件无关。
-
MaxConnsPerHost控制最多复用几个 TCP 连接，不是并发请求数 - 设成 5 但开了 20 个 goroutine，结果是前 5 个建连接，后面 15 个排队等空闲连接，反而放大延迟
- 推荐组合：信号量设为业务目标并发数（如 10），
MaxConnsPerHost设为略大值（如 15），同时调大MaxIdleConns和MaxIdleConnsPerHost避免连接频繁重建
最容易被忽略的一点：文件句柄泄漏比 goroutine 泄漏更隐蔽——os.Open 成功后没 Close，哪怕信号量正常释放，系统 fd 也会耗尽。所以 Acquire 和 Release 只解决并发调度问题，defer f.Close() 才真正保底。
