os.ReadFile仅支持本地文件读取，无法处理分布式场景下的节点定位、副本一致性及网络分区问题，必须通过元数据服务路由请求。
为什么不用 os.ReadFile 直接做分布式文件读取
因为 os.ReadFile 只操作本地路径，无法感知文件在哪个节点、是否副本一致、有没有网络分区。分布式场景下，你得先查元数据服务（比如用 etcd 或 consul），再选可用的存储节点，最后发起 HTTP 或 gRPC 请求拉取内容——这整个链路里，os.ReadFile 最多只能用在单个存储节点内部。
常见错误是：本地开发时一切正常，一上集群就报 no such file or directory，其实是因为代码硬编码了路径，没走元数据路由。
- 所有文件路径必须抽象为全局唯一 ID（如
file_id），而非本地文件系统路径 - 读请求需先调
metadataService.GetLocation(file_id)获取节点列表 - 客户端应实现简单负载策略（如轮询或最低负载节点），而不是固定连某台机器
- 务必设置超时和重试：gRPC 调用建议用
context.WithTimeout(ctx, 5*time.Second)
如何用 raft 同步元数据而非文件本体
文件内容太大，不适合放进 Raft 日志；但文件名、大小、分片位置、版本号这些元数据很轻，适合用 raft（比如 hashicorp/raft）做强一致性同步。这样既保证多节点间目录结构一致，又避免日志爆炸。
容易踩的坑是把整个文件二进制塞进 Apply()，导致 Raft 日志增长过快、快照失败、节点反复重放日志卡住。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 只在
Apply()中提交结构体如struct{ FileID string; Size int64; Nodes []string } - 快照（snapshot）只需保存当前元数据哈希表，不用包含实际文件块
- 每个存储节点启动时，先从本地磁盘加载元数据快照，再回放未快照的日志
- 注意
raft的Leader切换期间，写请求要排队或返回503 Service Unavailable，不能静默降级
io.Copy + http.Request.Body 处理大文件上传时的内存陷阱
直接用 io.Copy 把 http.Request.Body 写入磁盘没问题，但若中间加了校验（如计算 sha256）、加密或分片逻辑，就容易意外把整个文件读进内存——尤其是用 bytes.Buffer 或 io.ReadAll。
典型现象：上传 2GB 文件时，Go 进程 RSS 突增 2.1GB，然后被 OOM killer 干掉。
- 始终用流式处理：
hash := sha256.New(); io.Copy(hash, request.Body)，不要先ReadAll - 分片上传时，每个分片用独立的
io.Pipe或临时文件，避免缓冲区累积 - HTTP handler 必须设
MaxMultipartMemory（如16 ），防止 form 表单解析吃光内存 - 上传完成后，用
os.Stat校验文件大小，别信Content-Length头（可能被篡改）
为什么 go build -ldflags="-s -w" 对存储节点很重要
生产环境的存储节点常部署在资源受限的边缘机或容器中，而默认 Go 二进制含调试符号和 DWARF 信息，体积可能翻倍。更大的二进制意味着更慢的容器拉取、更高的内存映射开销，还可能触发某些安全策略拦截。
更关键的是，未 strip 的二进制在 panic 时会打印完整路径和行号——这在跨团队运维时可能暴露内部目录结构或模块命名习惯。
-
-s去除符号表，-w去除 DWARF 调试信息，两者通常一起用 - CI 构建阶段应强制加入该 flag，避免手工漏掉
- 若需保留部分调试能力，可用
-buildmode=pie配合strip --strip-unneeded替代 - 注意：strip 后
pprof的行号信息丢失，线上性能分析需依赖 symbol 文件单独存档
checksum 对账任务跑在后台。 
