gRPC-Go服务端支持v1/v2并行注册的关键是避免重复注册同名service，需通过独立ServiceDesc、路径前缀（如/v1.MyService/）、自定义Server及UnaryInterceptor解析method并路由到对应handler实现隔离。
gRPC-Go 服务端如何支持 v1/v2 并行注册
关键不是“升级”，而是让新旧版本同时跑起来，且不互相干扰。gRPC-Go 默认不允许同名 service 多次注册，grpc.RegisterService 会 panic。必须用 grpc.ServiceDesc + 自定义 Server 实现多版本路由入口。
常见错误现象：panic: service registration is not allowed after server starts 或调用时始终命中旧版，新版无响应。
- 每个版本定义独立的
ServiceDesc，路径前缀区分（如/v1.MyService/和/v2.MyService/） - 不用
grpc.NewServer()直接注册，改用grpc.ServerOption注入自定义serviceRegistrar - 在
UnaryInterceptor中解析method字符串，提取版本号并转发到对应 handler，避免重复注册 - 禁止复用同一
Server实例注册多个版本；若需共享监听端口，用net.Listener复用，但 handler 必须分拆
go.mod 中 v1/v2 模块路径怎么写才不冲突
Go 的模块系统靠导入路径识别版本，不是靠 tag 或分支。写错路径会导致编译失败或静默使用旧版。
典型错误：把 v2 模块仍声明为 module example.com/lib，导致下游 go get 无法区分 v1/v2。
立即学习“go语言免费学习笔记（深入）”；
- v1 版本保持原路径：
module example.com/lib - v2 版本必须带
/v2后缀：module example.com/lib/v2 - 下游引用 v2 时，import 必须写成
"example.com/lib/v2"，不能省略/v2 - 不要用
replace临时指向本地 v2 路径却保留 v1 导入路径——这会让构建结果不可重现
灰度流量如何从客户端精准打到指定 Golang 模块版本
不是靠 DNS 或 Service 名称，而是靠请求上下文里的显式标识。Kubernetes 或 Istio 只负责转发，真正路由决策在 Golang 应用内完成。
容易踩的坑：只在 Ingress 层做 header 路由，但 gRPC 的 header 是 metadata，HTTP/2 下 X-Canary-Version 不会自动透传到服务端逻辑。
- 客户端调用时必须用
metadata.Pairs("canary-version", "v2")显式注入 - 服务端用
grpc.MethodForGRPCMethod提取 method，再结合peer.FromContext(r.Context())获取 metadata - 别依赖
r.Header.Get—— gRPC 不走 HTTP header，那是 REST 场景 - 灰度标识建议统一用小写 key（如
canary-version），避免不同 Go 版本对 metadata key 大小写的处理差异
Docker 镜像里怎么确保运行时 Go 版本和构建时一致
镜像里 go version 显示的是构建环境的 Go，不是运行时实际执行的版本。如果二进制是用 go1.22 编译的，但基础镜像用的是 golang:1.21-slim，可能因 libc 或 TLS 协议差异崩溃。
最常被忽略的一点：Dockerfile 的 FROM 决定运行时环境，和构建阶段用的 Go 版本无关。
- 构建阶段用
golang:1.22.3，运行阶段也必须用golang:1.22.3-slim或至少相同 minor 版本的 alpine - 禁止在
FROM scratch镜像中直接拷贝二进制——它缺少必要的动态链接库，尤其涉及 crypto/tls 或 net/http 时会 segfault - CI 构建命令必须显式指定 Go 路径，例如
/usr/local/go/bin/go build -o app .，而不是依赖$PATH中的 go - 上线前用
ldd app检查动态依赖，确认没有 missing libc 或 openssl 符号
