最直接有效的本地调试方式是绕过客户端代码，用grpcurl直连gRPC服务、curl/Postman调用HTTP接口；需确保gRPC开启反射或指定proto文件、明文连接配insecure.NewCredentials()，HTTP注意路由前缀、中间件拦截及Content-Type。
本地调试 Kratos 接口，最直接有效的方式是绕过客户端代码，用工具直连服务端验证逻辑是否正确——gRPC 接口用 grpcurl，HTTP 接口用 curl 或 Postman，关键不是“怎么发请求”，而是“怎么让请求能通、数据能对、问题能定位”。
gRPC 接口：用 grpcurl 直连，但必须处理好反射和明文配置
执行 grpcurl -plaintext localhost:9000 list 报 Failed to list services: server does not support the reflection API，不是 client 写错了，是服务端根本没开反射。
- 检查
internal/server/grpc.go中创建*grpc.Server时是否传了grpc.ReflectionProvider(reflection.GRPCServerReflector(srv))（Kratos v2.7+ 默认不启用） - 不想开反射？改用
-proto指定本地文件：grpcurl -plaintext -proto api/helloworld/v1/helloworld.proto localhost:9000 helloworld.v1.Greeter/SayHello - 带 body 的请求必须用
-d，且 JSON key 要严格匹配 proto 字段名（如"name"，不是"Name"）：-d '{"name": "kratos"}' - 本地调试务必显式传
insecure.NewCredentials()，漏掉会卡在context deadline exceeded或 panic
HTTP 接口：用 curl 发请求，但注意路由前缀和中间件拦截
Kratos 的 HTTP 路由默认不带全局前缀，/users/{id} 就是真实路径；但如果用了 srv.Group("/api")，那实际路径就是 /api/users/{id}——curl 地址写错，404 是必然的。
- 确认服务启动日志里打印的地址，比如
start http server at [::]:8000，就用curl http://localhost:8000/users/123 - 如果接口返回 401/403，大概率是 Group 绑定的
authMiddleware拦截了，临时注释掉或加测试 header：-H "X-Test-Auth: true" - 路径参数（如
{id}）和 query 参数（如?page=1）都要按定义传，Kratos 不自动转换下划线或大小写 - POST/PUT 请求注意
Content-Type: application/json，否则ctx.Request().Body可能读不到内容
客户端代码调不通？先查连接初始化和上下文传递
grpcurl 和 curl 都能通，但自己写的 client 调不通，问题 90% 出在 client 初始化环节，而不是业务逻辑。
- 检查
grpc.Dial的地址：是直连"127.0.0.1:9000"还是服务发现地址"discovery:///helloworld.service"？后者依赖注册中心，本地没起的话必然失败 - 确认
grpc.WithTransportCredentials设置正确：本地用明文必须是insecure.NewCredentials()，生产才用credentials.NewTLS(...) - 别只看
err != nil，要主动检查ctx.Err()——超时被 cancel 和网络失败表现一样，但原因完全不同 - 在
internal/client/grpc.go的 dial 后加拦截器打日志：log.Printf("[grpc] %s → %s, cost: %v", method, target, time.Since(start))，能快速判断是卡在连接、发送还是响应阶段
真正容易被忽略的是元数据传递和中间件顺序。比如你加了 tracing 中间件，但没在 client 初始化时注入 metadata，或者服务端 metadata 中间件没启用，链路就断了——这种问题不会报错，只会静默丢失信息。
