rpc server: service not found 是因注册中心未连通或服务名不一致所致，需检查 etcd/Nacos 状态、配置地址、服务名大小写、启动顺序及 -f 参数；client 调用超时则多因 TLS 未禁用，应加 WithInsecure()。
go-zero 服务启动报错 rpc server: service not found
这是刚用 go-zero 写 RPC 服务时最常遇到的错误，本质是注册中心没连上，或服务名没对齐。不是代码写错了，而是配置和启动顺序没配好。
常见原因和操作建议：
-
etcd或nacos没起，或者etc/config.yaml里Registry地址写错（比如写成http://127.0.0.1:2379，但 etcd 默认只监听http://localhost:2379） - RPC 服务的
ServiceName和调用方client.NewXXXClient里传的名称不一致——注意大小写和下划线，user-rpc≠userrpc - 服务启动太快，注册中心还没 ready 就去注册：加
sleep 2s或用zookeeper的重试机制，但更稳妥的是在main.go里加健康检查逻辑 - 用
go run启动时忘了传-f参数指定配置文件，导致加载了空配置，默认 registry 是空的
生成 RPC 接口后，client 调用返回 context deadline exceeded
这不是超时设置太短，而是底层连接根本没建起来。go-zero 默认用 grpc，但很多本地开发环境没开 TLS，而生成的 client 默认启用了 WithTransportCredentials。
解决方法很直接：
立即学习“go语言免费学习笔记（深入）”；
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 在 client 初始化时显式禁用 TLS：
client := NewUserClient("user-rpc", etcdConf, client.WithNonBlock(), client.WithInsecure()) - 确认服务端
server.NewServer是否传了server.WithTransportCredentials；如果没配证书，服务端也得加server.WithInsecure() - 检查
etcd里是否真有该服务的 key：用etcdctl get --prefix ""看有没有/go-zero/下对应服务名的节点 - 别用
localhost做服务发现地址——Docker 容器里解析不了，换成宿主机 IP 或host.docker.internal
goctl api go 生成的 HTTP 服务无法解析 application/json 请求体
默认生成的 handler 不会自动绑定 JSON 字段，尤其当你在 .api 文件里写了 post /user/add (AddReq)，但请求体始终是空结构体。
关键点就两个：
-
AddReq结构体字段必须首字母大写 + 加json:tag，比如Name string `json:"name"`，小写字段不会被反序列化 - HTTP 路由定义里不能漏掉
requestBody显式声明，正确写法是：post /user/add (AddReq)，而不是post /user/add（后者不会注入 body 绑定逻辑） - 生成后检查生成的
handler文件，确认有没有var req AddReq+c.ShouldBind(&req)这两行；没有说明goctl版本太低（v1.5+ 才默认加） - 别手动改生成的 handler —— 下次
goctl重生成会覆盖，应该改.api文件或用goctl api plugin扩展模板
多个微服务共用一套 go-zero 配置，如何避免 redis / mysql 连接互相污染
go-zero 的 conf.MustLoad 是全局单例，所有服务 import 同一个 config struct 时，如果都用 redis.MustNewRedis，会复用同一个连接池，但不同服务的 DB 名、密码、甚至 Redis DB index 往往不同。
实际做法是分层隔离：
- 每个服务维护自己的
config.yaml，不要共用顶层 config struct；哪怕字段一样，也各自定义 struct，比如UserConfig和OrderConfig - 连接初始化放在 service 自己的
internal/logic或internal/svc里，而不是在global包里统一 new；这样连接池生命周期和服务绑定 - MySQL 连接字符串里明确写
parseTime=true&loc=Asia%2FShanghai，否则时间字段可能解析成 UTC，且不同服务 locale 不一致会导致时区错乱 - Redis 如果用 sentinel，
Addr必须写成sentinel1:26379,sentinel2:26379形式，不能只写一个 sentinel 地址，否则 failover 后连接中断
真正麻烦的从来不是怎么写，而是 config struct 里一个字段没对齐、一个 tag 漏了、一个地址少写了端口——这些地方一错，日志里几乎不报错，只默默返回空值或超时。
