go框架不内置负载路由算法，需在api网关等场景自行实现；director中必须重写req.url.path（trimprefix截前缀）和req.host（显式设目标服务host），否则90%请求因404或鉴权失败。
Go 框架本身不内置“负载路由算法”——http.ServeMux、gin.Engine、chi.Router 都只做路径匹配和中间件调度，不参与后端节点选择。真正需要算法介入的场景，是当你用 Go 写 API 网关、服务网格边车或客户端负载均衡器时，才必须自己实现或集成节点分发逻辑。
Director 函数里不重写 req.URL.Path 和 req.Host 就会 404 或鉴权失败
用 httputil.NewSingleHostReverseProxy 做转发时，Director 是唯一可控入口。这里漏改两处，90% 的请求会出问题：
-
req.URL.Path必须用strings.TrimPrefix(req.URL.Path, "/api/v1")截掉网关前缀，否则后端收到/api/v1/users却只注册了/users路由，直接 404 -
req.Host必须显式设为目标服务域名（如"user-svc.default.svc.cluster.local"），它和req.URL.Host完全无关；很多服务靠 Host 头做租户隔离或证书校验，透传客户端 Host 就会鉴权失败 - 前缀字符串必须完全一致：多一个斜杠、大小写错、结尾带不带
/，TrimPrefix都不生效
轮询（RoundRobin）不能靠全局变量或锁，得用原子计数器
手写轮询最常见错误是用 var idx int + mu.Lock()，高并发下锁争用严重。正确做法是：
Skill Weave Chains — 技能链路由引擎
下载
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- 声明
var counter atomic.Uint64 - 每次选节点时：
idx := atomic.AddUint64(&counter, 1) % uint64(len(nodes)) - 避免取模时
len(nodes)为 0，需前置检查或兜底返回默认节点 - 如果节点列表动态变化（如服务发现更新），轮询索引应绑定到当前快照，而非共享全局计数器，否则可能跳过新增节点
一致性哈希不是 crc32.Sum([]byte(key)) % len(nodes)
这是最典型的伪一致性哈希。真的一致性哈希必须建环、加虚拟节点、顺时针查找：
- 哈希值必须是
uint32，推荐用crc32.ChecksumIEEE([]byte(key))，别用md5或maphash（输出位宽不匹配） - 每台物理节点生成 20–60 个虚拟节点，例如
crc32.ChecksumIEEE([]byte(nodeName + "-1"))，不能用rand生成 - 环结构必须是排序后的
[]uint32，查找用sort.Search，返回索引后要再做i % len(ring)回绕 - 节点增减后必须调用
c.Rebuild()（若用github.com/hashicorp/consul/api/consistent），否则Get()仍查旧环
健康检查不联动负载池，算法再好也白搭
无论轮询还是哈希，如果节点已宕机还持续转发，就等于把流量往死路上导：
- 健康探测必须异步运行，用
time.Ticker定期对每个节点发HEAD /health，超时用context.WithTimeout控制 - 连续失败 N 次（如 3 次）才标记为不可用，并从可用节点池中移除；恢复后需主动重新加入，不能等下次探测自动回填
- 请求分发时只在当前可用池内选节点；若池为空，必须返回
http.StatusServiceUnavailable，不能 panic 或卡住 - 别依赖
net.DialTimeout当健康状态——TCP 连通 ≠ HTTP 服务可用，一定要走业务健康接口
算法只是骨架，真正决定稳定性的，是节点状态能否实时反映到路由决策里。环再稳，节点挂了没人通知，所有请求照样雪崩。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
