在Go语言中构建并发文件下载器时，核心难点并不在于发起多个HTTP请求，而在于如何将不同协程获取到的数据块正确落到文件的对应位置。如果处理不当，即便各协程都成功拿到了数据，最终文件也会出现空洞、覆盖或乱序。解决这一问题的关键，是理解普通写入接口与带偏移写入接口在并发下的行为差异。
为什么普通Write不适合并发写入
Go的os.File实现了io.Writer接口，其Write方法从文件当前偏移量开始写入，然后自动后移偏移量。这个“当前偏移量”是文件描述符层面的状态，被所有操作同一文件的goroutine共享。当多个协程同时调用Write时，协程A刚写完一段，偏移已被改动，协程B的Write就会从新偏移开始，导致本应写在后面的数据被提前覆盖，或者两块数据纠缠在一起。
下面这段代码模拟了错误用法：两个协程向同一个文件写入不同内容，由于没有控制偏移，最终文件内容取决于调度顺序，无法保证布局正确。
package main
import (
"os"
"sync"
)
func main() {
f, _ := os.Create("broken.bin")
defer f.Close()
var wg sync.WaitGroup
wg.Add(2)
go func() {
defer wg.Done()
// 试图写入前一半，但偏移可能被另一个协程改动
f.Write([]byte("AAAAAAAAAA"))
}()
go func() {
defer wg.Done()
f.Write([]byte("BBBBBBBBBB"))
}()
wg.Wait()
}
这种写法在单协程下没有问题，但一旦并发，文件内容就不可控。更隐蔽的是，某些运行时看似正常，只是因为协程恰好串行执行，这给排查带来了很大麻烦。
WriteAt的底层机制与优势
WriteAt的方法签名为WriteAt(b []byte, off int64) (n int, err error)，它不依赖文件当前偏移，而是每次调用都显式指定从哪个字节位置开始写。内核会根据传入的偏移直接定位，多个协程即使同时调用，只要off区间不重叠，就能互不干扰地写满文件。
从实现角度看，WriteAt通常映射到pwrite系统调用（Linux下），该调用是线程安全的，且不会影响文件描述符的偏移指针。因此，我们可以把文件按大小切分为若干块，每块分配一个起始偏移，交给独立协程下载并写入，完全不需要加锁保护写入动作本身。
// 以偏移方式写入，不关心文件当前游标
n, err := f.WriteAt(chunkData, int64(index)*chunkSize)
if err != nil {
// 处理写入错误
return err
}
if n != len(chunkData) {
return io.ErrShortWrite
}
上面的片段展示了一个典型调用。只要index*chunkSize计算准确，各协程写出的数据就会各居其位。需要注意的是，最后一小块可能不足chunkSize，计算偏移时仍用索引乘基准大小即可，实际写入长度以数据为准。
基于WriteAt的并发下载器实现
一个实用的下载器通常先发起HEAD请求获取文件总大小，然后按并发数切分区间，每个协程使用HTTP Range请求对应字节段，再用WriteAt落盘。下面给出完整示例：
package main
import (
"fmt"
"io"
"net/http"
"os"
"strconv"
"sync"
)
func main() {
url := "https://ipipp.com/sample.bin"
concurrency := 4
err := download(url, "output.bin", concurrency)
if err != nil {
fmt.Println("下载失败:", err)
} else {
fmt.Println("下载完成")
}
}
func download(url, dest string, concurrency int) error {
resp, err := http.Head(url)
if err != nil {
return err
}
size := resp.ContentLength
if size <= 0 {
return fmt.Errorf("无法获取文件大小")
}
f, err := os.Create(dest)
if err != nil {
return err
}
defer f.Close()
chunkSize := size / int64(concurrency)
var wg sync.WaitGroup
errCh := make(chan error, concurrency)
for i := 0; i < concurrency; i++ {
wg.Add(1)
start := int64(i) * chunkSize
end := start + chunkSize - 1
if i == concurrency-1 {
end = size - 1
}
go func(i int, start, end int64) {
defer wg.Done()
req, _ := http.NewRequest("GET", url, nil)
req.Header.Set("Range", "bytes="+strconv.FormatInt(start, 10)+"-"+strconv.FormatInt(end, 10))
r, e := http.DefaultClient.Do(req)
if e != nil {
errCh <- e
return
}
defer r.Body.Close()
buf := make([]byte, 32*1024)
off := start
for {
n, re := r.Body.Read(buf)
if n > 0 {
wn, we := f.WriteAt(buf[:n], off)
if we != nil {
errCh <- we
return
}
off += int64(wn)
}
if re == io.EOF {
break
}
if re != nil {
errCh <- re
return
}
}
}(i, start, end)
}
wg.Wait()
close(errCh)
for e := range errCh {
if e != nil {
return e
}
}
return nil
}
该实现中，每个协程只负责自己的一段Range，通过WriteAt从start开始顺序写入。由于偏移由变量off在协程内维护，且初始值就是分配区间的起点，协程之间不存在任何共享写入位置，因此不需要互斥锁。
使用errCh收集错误是为了避免某个协程失败被静默忽略。主协程在wg.Wait后检查通道，只要有一个错误就向外返回。实际工程中还可加入重试逻辑，对失败区间重新拉取，而不必整体重来。
工程实践中的注意事项
首先是buffer复用。示例中每个协程都make了独立buffer，这避免了协程间slice底层数组竞争。如果图省事使用全局buffer并加锁，反而抵消了并发写入的优势，不如直接让各协程持有私有缓冲。
其次是文件预分配。某些文件系统在不连续写入时会产生大量碎片，或在某些系统上WriteAt跳过偏移会生成“稀疏文件”。可以在创建文件后调用f.Truncate(size)提前占满空间，让后续写入只是填洞，提升稳定性。
// 提前扩展文件至目标大小
if err := f.Truncate(size); err != nil {
return err
}
最后是退出清理。如果下载中途出错，残留的半成品文件应当删除或标记，否则下次运行可能误判已完成。可以在函数返回错误前调用os.Remove(dest)，或者由调用方根据错误决定是否保留。
性能与适用边界
并发下载并非越多越好。线程数超过磁盘随机写入吞吐或远端服务器限流后，收益会递减甚至下降。一般本地磁盘建议并发在4到8之间，网络带宽受限时则可适当提高，但需配合超时控制。
对于已经支持断点续传的CDN，Range请求非常稳定；若服务端不支持Range，则无法使用分块并发，只能退回单流下载。此时WriteAt虽仍能用于追加写，但已无并发优势。因此在动手前，先用HEAD或OPTIONS确认服务端响应头中的Accept-Ranges字段是必要的一步。
综上，WriteAt以显式偏移消除了文件游标竞争，是Go并发下载器落盘的正确选择。配合Range请求与合理的协程模型，既能保证数据准确，也能充分利用带宽与CPU。