go-micro v4 兼容性问题有三：服务名须显式配置（如micro.Name("user-srv")）、Init必须在Run前调用以完成注册校验、Client默认直连localhost:8080，需显式传registry或address。
go-micro v4 已不兼容老项目代码，直接照搬 v2/v3 教程必报错，核心问题就三个：服务名必须显式传、Init 和 Run 顺序不能乱、Client 默认不走注册中心。
micro.NewService 报 “no service name” 怎么修
v4 强制要求显式配置服务名，空字符串、默认值、下划线命名全被拒绝。etcd/consul 的 key 路径不支持 _，一用就静默失败，查不到服务也无报错。
- 必须写
micro.Name("user-srv")，不能只写micro.NewService() - 服务名只能含小写字母、数字、短横线（
-），user_service或UserSrv都会注册失败 - 若需命令行传参，得自己加
flag.String("name", "user-srv", "")，再传给micro.Name(*serviceName)，框架不自动绑定 flag
service.Init() 和 service.Run() 为什么不能调换顺序
Init 不只是初始化，它会校验 registry、broker、transport 配置合法性，并触发节点注册逻辑。Run 前没 Init，等于让服务“裸奔”——看似启动成功，但根本没进注册中心，其他服务发现不了你。
- 典型现象：
curl http://localhost:8080/health404 或超时；micro list services查不到本服务；日志里没有Registering node或Starting server - 唯一正确顺序：
service.Init()→service.Handle()→service.Run() - 如果用了
micro.Flags，Init 会解析这些 flag；跳过 Init 就等于跳过所有前置检查
micro.NewClient 总连 localhost:8080 怎么改
Client 默认 transport 是 HTTP，且未配 registry 时，它不会查服务发现列表，而是直连硬编码地址 localhost:8080。这不是 bug，是设计上把“是否走注册中心”当作显式选项。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 想走服务发现：初始化 client 时传
micro.Registry(service.Registry())，确保和 service 用同一个 registry 实例 - 想直连固定地址（如本地调试）：用
micro.WithAddress("10.0.1.5:9090")，此时 registry 配置会被忽略 - 跨语言调用（比如 Python micro service）：必须加
micro.WithContentType("application/json")，否则默认用 protobuf+binary 编码，对方解不开
proto 文件生成后，调用必须走 service.Client().Call
直接 new grpc.ClientConn 绕过了 go-micro 的负载均衡、重试、selector 等中间层逻辑，看似能通，实则失去微服务治理能力。
- 正确调用方式：
service.Client().Call(ctx, req, rsp, client.WithRetries(0)) - v4 的
Call默认带 3 次重试 + 指数退避，QPS 高时可能掩盖真实超时，建议按需关闭或自定义 selector - 生成代码依赖
protoc-gen-micro，不是protoc-gen-go；命令是protoc --micro_out=. xxx.proto
最麻烦的从来不是“怎么让两个服务通上”，而是“通上之后，当 Nacos 重启、网络抖动、服务实例闪退时，你的重试逻辑有没有覆盖所有超时分支”。v4 的插件链是显式拼装的，少一个 transport 或 codec 配置，就可能在某个环境静默失败。
