高可用网关依赖无状态部署、服务发现联动、多级容错闭环和配置热生效四点落地，Go仅提供底座，所有能力须显式编码或集成；Kratos Gateway启动失败主因是conf.Load()未前置调用且配置路径缺失，HTTP 404源于路由未手动绑定，wrr负载均衡需自定义RoundTripper并填充Weight字段，工业协议网关不可套用httputil.ReverseProxy。
直接说结论：高可用网关不是靠“选一个框架堆功能”实现的，而是靠无状态部署、服务发现联动、多级容错闭环和配置热生效这四点落地——Go 语言本身只提供并发与网络底座，所有高可用能力必须显式编码或集成，不存在开箱即用的“高可用网关框架”。
kratos.New() 启动就 panic，但没报配置文件路径
这是 Kratos Gateway 最典型的启动失败场景。panic 原因是 kratos.New() 内部立即调用 conf.Load()，而你还没注册任何 config.Provider。
- 必须在
main()函数第一行执行conf.Load(config.NewFile("configs/gateway.yaml"))，不能等日志初始化、flag 解析之后再做 -
configs/gateway.yaml必须存在且可读，conf.Load()返回 error 时要显式检查并退出，否则后续 panic 更难定位 - 别依赖
$CONFIG_PATH环境变量自动替换：config.NewFile(os.Getenv("CONFIG_PATH"))需手动拼接，Kratos 不解析变量语法
HTTP 路由 404，但 gRPC 服务能连上
说明进程存活、HTTP Server 已启动，但路由根本没挂到 mux 上。Kratos Gateway 的 HTTP 路由不自动扫描注册，全靠手动绑定。
- 确认
internal/server/http.go中创建了http.NewServer()实例，并传入了 handler（通常是*gin.Engine或自定义http.ServeMux） - 确认
api/v1/gateway_http.pb.go已生成（即执行过make api），否则v1.RegisterGatewayHTTPServer()函数不存在 - 确认 proto 中
option (google.api.http)声明的路径带前缀，比如get: "/v1/route"，不是get: "/route"；该前缀是代码生成时硬编码的 - 漏传
httpSrv到kratos.New(kratos.Server(httpSrv, grpcSrv))，等于没启用 HTTP 监听
wrr 负载均衡策略不生效
Kratos 默认的 Selector 实现只在 Client 层起作用，而 Gateway 的 Proxy 流程绕过了它——Proxy 直接拿 Node 列表转发，不走 Selector.Select()。
立即学习“go语言免费学习笔记（深入）”；
- 必须自定义
proxy.RoundTripper，在RoundTrip()中手动调用selector.Select()获取目标节点 - 原生
wrr策略依赖discovery.Instance的Weight字段，确保服务注册时填了该字段（如 Consul 的meta["weight"]） - 别在
selector.WithPolicy()上浪费时间，它对 Gateway Proxy 无效
工业协议网关不能用 httputil.ReverseProxy
Modbus/TCP、IEC 60870-5-104 等工业流量不是 HTTP，套用 httputil.ReverseProxy 必然在现场崩溃——TCP 底层控制完全缺失，不是功能补丁能解决的。
-
ReverseProxy不调用SetNoDelay(true)，Nagle 算法攒包导致设备端超时断连 - 对
net.Conn的读写 deadline 完全无感知，一次阻塞Read就卡死几十秒 -
io.Copy默认分配 32KB buffer，高频轮询下 GC 频繁，CPU 满载但吞吐不足 30% - 必须手动接管：Accept 后断言
*net.TCPConn并设SetNoDelay、SetKeepAlive；每次Read/Write前动态设SetReadDeadline；用sync.Pool复用bufio.Reader/Writer
真正麻烦的从来不是写转发逻辑，而是把健康检查、熔断器、服务发现、配置热更新这四个环扣严实——任一环节松动，高可用就只剩名字。
