根本原因是 sidecar 未就绪或服务未按 Dapr 约定暴露健康/接口端点：需监听 0.0.0.0:3000、实现 /healthz、显式指定 --app-port，并用 dapr.Client 调用以启用熔断等能力。
为什么 dapr run 启动服务后调用 500 或超时？
根本原因通常是 sidecar 未就绪，或服务没按 Dapr 约定暴露健康/接口端点。Dapr 的 sidecar 默认等待目标服务在 :3000（或其他指定端口）返回 HTTP 200 健康响应才开始转发流量；如果服务启动慢、没实现 /healthz，或监听地址写成 127.0.0.1:3000（导致 sidecar 无法从容器内访问），就会卡住或报错。
- 确保 Go 服务启动后监听
0.0.0.0:3000，不是localhost:3000或127.0.0.1:3000 - 加一个最简健康接口：
http.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) { w.WriteHeader(200) }) - 用
dapr run --app-port 3000 --dapr-http-port 3500 --app-id order-service go run main.go显式指定端口，避免默认猜测失败 - 启动后立刻执行
curl http://localhost:3500/v1.0/healthz和curl http://localhost:3500/v1.0/invoke/order-service/method/healthz验证连通性
如何让 Go 服务安全调用另一个 Dapr 应用的 API？
Dapr 不强制你手写 HTTP 客户端拼 URL，而是推荐用 dapr.Client 封装了服务发现和重试逻辑。直接发请求到 http://localhost:3500/v1.0/invoke/payment-service/method/pay 虽然可行，但绕过了 Dapr 的熔断、gRPC fallback、TLS 自动启用等能力。
- 用官方 SDK：
go get github.com/dapr/go-sdk/client - 初始化 client 时传入
dapr.WithServerAddress("localhost:3500")，不要硬编码 localhost —— 在 Kubernetes 中应改为dapr-api.dapr-system.svc.cluster.local:80 - 调用时用
client.InvokeMethod(ctx, &dapr.InvokeMethodRequest{Method: "pay", Data: payload, ContentType: "application/json"})，Dapr 自动解析payment-service对应的实例地址 - 别把
method当成路径前缀；method: "v1/process"是合法的，Dapr 不做路径校验，由目标服务自己处理
dapr publish 发布事件后消费者收不到？
常见于没配对 Pub/Sub 组件，或订阅方没正确声明 topic。Dapr 的发布/订阅不是“发了就有人听”，而是依赖组件配置 + 主动注册。Go 服务必须显式调用 server.AddTopicEventHandler 并启动 HTTP server，否则 Dapr sidecar 根本不知道该往哪推消息。
- 确认
components/pubsub.yaml已部署（如 Redis 或 Kafka），且metadata.name和代码中pubsubName一致 - Go 订阅端必须起一个 HTTP server，并注册 handler：
server.AddTopicEventHandler("orders", handler)，handler 函数签名必须是func(context.Context, *pubsub.NewMessage) error - 发布时指定 pubsub 名：
client.PublishEvent(ctx, "orderpubsub", "orders", data)，其中"orderpubsub"必须匹配组件文件里的metadata.name - 检查日志：运行
dapr logs -k order-consumer（K8s）或看本地dapr run输出，搜索subscribed to topic关键字
State Store 写入后读不到，或者并发更新丢失？
Dapr 的 state API 默认不保证强一致性，也不自动加锁。Go SDK 调用 client.SaveState 成功，不代表其他实例立刻能读到最新值；更危险的是，多个请求同时读-改-写，会覆盖彼此的变更。
立即学习“go语言免费学习笔记（深入）”；
- 读操作加 ETag 检查：
client.GetState(ctx, "mystore", "cart-123", &state.GetStateOption{Consistency: "strong"})，注意strong仅对支持的后端（如 Redis、ETCD）生效 - 写入时带上
Etag做乐观并发控制：client.SaveState(ctx, "mystore", "cart-123", data, &state.SaveStateOption{Etag: etag})，失败时会返回ETAG_MISMATCH错误 - 避免在 Go 里自己实现“先查再改”逻辑，改用
client.ExecuteStateTransaction批量提交原子操作（如扣库存+记日志） - 别把
state store当数据库用：它不支持 SQL 查询、索引或事务回滚，只适合 KV 场景
真正麻烦的从来不是怎么写那几行 client.PublishEvent，而是搞清每个参数背后绑定的组件状态、网络拓扑和一致性模型——这些信息分散在 YAML 文件、CLI 参数、SDK 调用链和集群环境里，漏掉任何一环，服务就静默失联。
