Go本身不处理文件请求的负载分配，仅分发HTTP请求；高并发文件请求需由Nginx/Envoy等接入层做反向代理与缓存，Go调度层仅提供轻量路由（如302重定向或后端地址），存储层专注文件读写，三者分工协作。
Go 本身不处理「文件请求的负载分配」——它只管 HTTP 请求分发，文件读写是后端服务或存储层的事。所谓“高并发文件请求”，本质是大量 HTTP 客户端请求 /files/xxx.pdf 这类路径，而你得决定：这些请求该打到哪台文件服务器、对象存储网关，或本地磁盘节点上。
为什么不能直接用 net/http 做文件路由
常见误区是把 http.ServeFile 或 http.FileServer 直接暴露给公网，再靠 Go 自己轮询多个磁盘目录。这会导致：
- 每个请求都触发
os.Open和系统调用，无连接复用、无缓存感知，CPU 和 I/O 都被压垮 -
http.FileServer不支持跨机器路径映射，无法把/files/a.jpg动态转发到http://node2:8080/files/a.jpg - 没健康检查，某台文件节点磁盘满或进程卡住，请求仍持续打过去，错误率飙升
- 所有文件元信息（大小、修改时间、ETag）都得实时 stat，无法利用 CDN 或代理层缓存
真正可行的三层分工模型
高并发文件场景下，负载分配必须拆成三段，每段各司其职：
- 接入层（反向代理）：用 Nginx / Envoy / Traefik 做 TLS 终结、URL 路由、缓存头控制、限速。它不碰文件内容，只做七层转发
-
调度层（Go 服务）：不处理文件 I/O，只响应
/resolve?path=/a.jpg这类轻量 API，返回 302 重定向或后端地址（如{"backend":"http://fs-03:9000"}），并附带签名、过期时间等安全字段 -
存储层（真实文件节点）：运行 MinIO、Ceph RGW、或自建 Go 文件服务（带
io.Copy流式传输、http.ServeContent支持 Range）、挂载 NFS/CephFS。它专注读写，不做路由逻辑
Go 调度层该用什么算法选节点
别在 http.HandlerFunc 里写轮询计数器。正确做法是封装 RoundTripper 或独立调度函数，按需选择：
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
轮询（
RoundRobin）：适合节点性能一致、文件大小均匀的场景；用atomic.Uint64算索引，避免锁争用 -
最少连接（
LeastConnections）：更适合大文件下载，因为长连接会堆积；需每个节点上报当前活跃连接数（通过心跳接口或 Prometheus 拉取） -
一致性哈希（
ConsistentHash）：按文件路径哈希，确保同一文件总落到同一节点，利于本地磁盘缓存命中；但节点增减时部分 key 会迁移 -
加权随机（
WeightedRandom）：根据节点磁盘剩余空间、CPU 负载动态调整权重；需定期从/metrics或/health接口拉取指标
注意：所有算法都依赖后端节点列表的实时性。别硬编码 []string{"10.0.1.10", "10.0.1.11"}，应从 Consul/Etcd 拉取，并用 sync.Map 缓存，更新时用 CAS 替换整个 map，避免读写冲突。
最容易被忽略的细节：Range 请求和 ETag 分发
浏览器下载大文件时会发带 Range: bytes=0-1023 的请求，CDN 或代理可能缓存部分片段。如果你用 302 重定向，客户端可能把 Range 头带到新地址，但目标节点若没正确处理，就返回 200 全量内容，浪费带宽。
必须确保：
- 调度层不改写
Range和If-None-Match头，原样透传 - 每个文件节点自己生成 ETag（如
md5(file_path + mtime)），不要由调度层统一算 - 若用 302，重定向 URL 必须包含完整路径和查询参数（如
http://fs-02:9000/files/report.pdf?v=20260614），否则 CDN 缓存键不一致 - 对 HEAD 请求也走同样调度逻辑，否则缓存系统查不到元信息就降级为 GET
文件不是普通 API，它的缓存行为、连接生命周期、错误恢复机制都更复杂。调度层越薄越好，把压力留给专做文件的组件。
