sync.Map 专为读多写少、键生命周期长的并发场景设计，避免普通 map 的 fatal error: concurrent map read and map write；它通过 read/dirty 双层结构实现无锁读，但不支持 range、len 等操作，也非普通 map 的线程安全替代品。
为什么用 sync.Map 而不是普通 map 存任务状态
因为下载任务常被多 goroutine 并发读写：一个 goroutine 启动下载并更新状态，另一个可能在 HTTP handler 里查进度。普通 map 非并发安全，直接读写会 panic：fatal error: concurrent map read and map write。sync.Map 是标准库专为高读低写场景设计的线程安全映射，不用额外加锁就能存取任务 ID 到状态的映射，比如：map[string]DownloadTask。
注意它不支持遍历（range 不可用），如果后续需要批量查所有任务，得额外维护一个 sync.RWMutex + 普通 map，但对简单队列来说，按 ID 查足够了。
http.ServeFile 不能直接用于动态下载任务管理
很多人第一反应是用 http.ServeFile 返回文件，但它只适合静态路径已知、权限可控的场景。下载任务管理队列的核心需求是：用户提交 URL → 后端异步拉取 → 存临时目录 → 提供带进度的下载地址。这中间涉及网络 IO、状态跟踪、超时控制，http.ServeFile 完全不参与。
实际做法是：用 net/http 自定义 handler，根据任务 ID 从 sync.Map 查状态；若已完成，用 http.ServeContent（不是 ServeFile）流式返回本地文件，支持断点续传；若进行中，返回 JSON 进度；若失败，返回错误码和消息。
关键点：http.ServeContent 需要提供 modtime 和 size，且必须用 io.ReadSeeker 包裹文件，否则无法处理 Range 请求。
用 time.AfterFunc 做超时清理很危险
给每个下载任务配一个 time.AfterFunc 来删临时文件，看似合理，但容易导致资源泄漏：如果任务提前完成或失败，AfterFunc 仍会执行，可能删掉刚写完还没被下载的文件；更糟的是，它无法取消——Go 1.22 之前没有原生可取消的定时器。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
正确做法是统一用 context.WithTimeout 控制下载过程，并在任务结束（无论成功失败）时，显式触发清理：
- 把临时文件路径存在
DownloadTask结构体里 - 用
defer os.Remove或单独 goroutine +select等待任务完成信号 - 避免依赖“时间到了就删”，而依赖“任务生命周期结束就删”
如何让多个下载并发但限制最大数（如最多 3 个同时跑）
靠 channel 当计数信号量最轻量。声明一个带缓冲的 channel：sem := make(chan struct{}, 3)，每次启动新下载前先 sem ，下载结束时再 。这样天然阻塞超额请求，无需锁或原子操作。
注意别在 HTTP handler 里直接 go download(...) 就完事——必须把 放在 goroutine 内部结尾，否则 handler 会卡住。典型结构：
go func() {
sem <p>如果用第三方队列库（如 <code>machinery</code>），反而引入不必要的序列化和 broker 依赖，对“简单文件下载队列”属于过度设计。</p><p>真正难的不是启动下载，而是怎么让失败重试不堆积、临时文件不占满磁盘、HTTP 接口不暴露真实路径——这些细节比选什么数据结构更影响线上稳定性。</p>
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
