Golang本身不提供块级数据校验的内置网关能力，必须手动集成校验逻辑到存储代理层；高可用由etcd选主、gRPC resolver动态发现、本地fallback缓存三者协同构成，且块级校验失败时须在200ms内完成故障闭环切换。
直接说结论：Golang 本身不提供块级数据校验的内置网关能力，必须手动集成校验逻辑到存储代理层；高可用不是靠“一键编译”实现的，而是由 etcd 选主、gRPC resolver 动态发现、本地 fallback 缓存三者协同构成。
etcd 服务注册与 Lease TTL 设置容易超时失败
很多团队把 etcd 当作配置中心用，却忽略它对网络抖动极其敏感。比如设置 lease.TTL = 5s，但节点间 RTT 波动超过 300ms，KeepAlive 就频繁断连，导致选主反复触发。
- 生产环境必须设
lease.TTL >= 15s，且在进程退出前调用Lease.Revoke()主动释放，别等自动过期 -
clientv3.New()初始化时禁用grpc.WithBlock()，改用grpc.WithTimeout(3 * time.Second)+ 重试机制 - 心跳检测不能只靠
Get()，要搭配Watch()监听 key 变更，否则节点宕机后 10s 内无法感知
块级校验逻辑必须绑定在 proxy 转发层而非 client 端
如果你把 CRC32 或 SHA256 校验放在客户端计算再传给网关，等于把校验责任推给不可信终端——攻击者可伪造校验值绕过验证。真正安全的做法是让网关在读取后端块设备（如裸盘、iSCSI LUN）或对象存储分片时，实时计算并比对。
- 使用
io.CopyN()+hash/crc32按固定blockSize=4096分块校验，避免整文件加载内存 - 校验失败时返回
http.StatusPartialContent并记录错误块偏移（offset）、期望 hash（expected）、实际 hash（actual） - 不要在
FSM.Apply()中做阻塞 IO，块校验结果应异步写入本地 WAL 日志，再由独立 goroutine 同步到 etcd / Prometheus
gRPC resolver 必须自实现才能支持服务发现
很多人用 grpc.WithBalancerName("round_robin") 却发现请求全打到第一个节点——因为 gRPC Go client 默认不解析 DNS SRV 记录，也不支持直接填 IP 列表。
立即学习“go语言免费学习笔记（深入）”；
- 若用 etcd 做服务发现，需自己实现
resolver.Builder，监听/services/storage-gateway下的节点列表并动态更新resolver.State - 禁用
dns:///host:port，Kubernetes 中 headless service 的 DNS 解析在 gRPC client 里默认不生效 - 客户端必须启用
grpc.WithConnectParams(grpc.ConnectParams{MinConnectTimeout: 5 * time.Second})，否则短连接频繁重建
最常被忽略的是：块级校验和高可用不是两个独立模块，而是一体两面——当某块校验失败时，网关必须能立刻切换到副本节点重读，这要求 etcd watch、resolver 更新、本地缓存 fallback 全部在 200ms 内完成闭环，任何一环超时都会放大故障影响。
