直接用 dgraph.client 会 panic：context deadline exceeded，因客户端未配置超时和重试，且默认 fallback 到 localhost:9080 而非真实集群地址；需显式创建带健康检查、超时及正确服务发现（如 alpha-headless）的 grpc 连接，并使用 newdgraphclientapi 初始化。
为什么直接用 dgraph.Client 会 panic：context deadline exceeded
微服务里一调 dgraph.Client.Query 就超时，不是 Dgraph 没起来，而是客户端没配超时和重试。Dgraph 的 Go SDK 默认使用 grpc.Dial，但不设 grpc.WithTimeout 或 grpc.WithBlock，连接建立阶段就可能卡死。更常见的是，你用了 dgraph.NewDgraphClient([]*dgraph.DgraphClient{}) 却没传入已连通的 gRPC 连接，结果所有请求都 fallback 到本地 localhost:9080 —— 而你的 Dgraph 集群其实在 k8s 里跑着 dgraph-zero 和 dgraph-alpha，地址根本不对。
- 必须显式创建带健康检查和超时的 gRPC 连接：
conn, err := grpc.Dial("alpha-headless.default.svc.cluster.local:9080", grpc.WithTransportCredentials(insecure.NewCredentials()), grpc.WithBlock(), grpc.WithTimeout(5*time.Second)) - 集群部署下，
alpha-headless是必需的 Headless Service，不能写成localhost或单点 IP - 初始化 client 时别漏掉
dgraph.NewDgraphClientApi(dgraph.NewDgraphClient(conn))，否则Mutate会报rpc error: code = Unimplemented desc = unknown service api.Dgraph
如何让 gqlgen 自动生成的 resolver 正确调用 Dgraph 的 Upsert 和 Query
gqlgen 默认生成的 resolver 用的是内存 mock，要对接 Dgraph，关键在把 *dgraph.DgraphClient 注入到 resolver context，而不是全局变量。否则并发请求会共享同一 client 实例，导致 ctx 被覆盖、事务混乱。
- 在 handler 层（比如 http handler）中把 client 包进 context：
ctx = context.WithValue(r.Context(), "dgraph_client", dgraphClient)
- resolver 函数里取 client：
client := ctx.Value("dgraph_client").(*dgraph.DgraphClient) - Upsert 必须带
upsert.Input{SetNquads: ..., Cond: ...}，Cond不能为空字符串，否则 Dgraph 当作普通 mutate 处理，不会去匹配已有节点 —— 常见错误是写成Cond: ""而不是Cond: "@if(eq(len(uid), 0))" - Query 语句里别用
expand(_all)，微服务高频调用时容易触发 Dgraph 内存暴涨；改用显式字段投影，比如{ name email posts { title } }
怎么处理 Dgraph 事务冲突：AbortError 和 Context canceled
Dgraph 的 txn.Commit() 不是原子成功，它可能返回 dgraph.ErrAborted（事务被其他写入 abort）或 context.Canceled（超时或父 context 关闭）。微服务里如果只做一次重试，大概率还是失败 —— 因为 Dgraph 的 abort 通常发生在高并发写同一批 uid 时，需要指数退避 + 限制重试次数。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 标准做法是封装一个带重试的
doInTxn函数，最大重试 3 次，每次 sleep10ms * (2^i) - 别在事务里做 HTTP 请求或数据库查询，Dgraph txn 期间持有锁，外部 IO 会拖长锁持有时间，加剧冲突
- 如果业务允许最终一致性，优先用
Upsert替代手动BeginTxn → Mutate → Commit，Upsert 本身是原子的，且自动处理存在性判断
为什么 Dgraph schema 更新后 gqlgen 生成的模型字段不生效
schema 改了（比如加了 friend: [uid] @reverse），但 gqlgen 生成的 Go struct 还是老样子，甚至编译都不报错 —— 因为 gqlgen 只读 schema.graphql，不读 Dgraph 的 live schema。而 Dgraph 的 schema 是运行时生效的，curl -X POST http://localhost:8080/alter -d '{"schema":"friend: [uid] @reverse"}' 成功后，必须同步更新本地 schema.graphql 文件，否则 gqlgen 不知道新字段存在。
- 建议把 Dgraph schema 导出脚本接入 CI：
curl -s http://dgraph-alpha:8080/schema | jq -r '.schema' > schema.dgraph
，再用工具转成 GraphQL SDL 格式写入schema.graphql - 字段类型映射要注意：
datetime对应 Go 的time.Time，但 Dgraph 返回的是 RFC3339 字符串，gqlgen 默认不会自动解析，得在 model 绑定层加UnmarshalGQL方法 - 反向边（@reverse）在 GraphQL 查询里是隐式字段，gqlgen 不会自动生成对应 struct 字段，得手动在
models_gen.go里补上，或者用map[string]interface{}临时兜底
Dgraph 的 schema 动态性和 gqlgen 的静态代码生成之间有天然张力，每次 alter schema 后，既要改 Dgraph 端，也要同步更新本地 schema 定义和 Go model，漏掉任何一环都会导致 runtime panic 或静默数据丢失。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
