绝大多数人用dgo客户端连Dgraph报context deadline exceeded，根本原因是默认配置未适配真实网络环境：dgo.NewDgraphClient()不自动重试、不设合理grpc.WithTimeout或grpc.WithBlock，服务端响应稍慢（如首次加载schema）即失败，须显式传入超时和连接参数。
为什么直接用 dgo 客户端连 Dgraph 会报 context deadline exceeded
绝大多数人在 Go 组件里第一次集成 Dgraph，卡在连接建立或查询超时——不是代码写错，而是默认配置没适配真实网络环境。Dgraph 的 gRPC 接口对连接健康度敏感，dgo.NewDgraphClient() 创建的客户端不自动重试、不设置合理的 grpc.WithTimeout 或 grpc.WithBlock，一旦服务端响应稍慢（比如首次加载 schema），就直接失败。
- 必须显式传入带超时和重试的
grpc.DialOption，例如：grpc.WithTimeout(10 * time.Second)和grpc.WithConnectParams(grpc.ConnectParams{MinConnectTimeout: 5 * time.Second}) - 别复用同一个
dgo.DgraphClient实例跨 goroutine 写操作——它内部的api.DgraphClient是线程安全的，但事务（txn := client.NewTxn()）不是，每个请求应新建txn - 开发环境连
localhost:9080时，确保 Dgraph 已启动且grpc端口（非 HTTP 8080）已暴露；Kubernetes 部署时，务必用 headless Service + DNS 名，避免用 ClusterIP 直连导致连接抖动
如何用 client.Assign() 正确批量写入带层级关系的节点
Dgraph 的 Assign 不是简单插入，它会触发 UID 分配、反向边推导和索引更新。如果一次塞进 500 个含 ~friend、~owned_by 等反向边的节点，很可能因 schema 中未定义对应 reverse edge 而静默失败，或因单次 payload 过大被 grpc 流控拦截。
- 先确认 schema 中已声明所有要用的 reverse edge，例如：
name: string @index(exact) .对应的~name才可用；没声明就用会丢数据 - 拆分批量写入：每批 ≤ 100 条，且每条只含正向边（
friend），反向边（~friend）由 Dgraph 自动补全——前提是 schema 里写了friend: uid @reverse . - 写完立刻调用
txn.Commit(ctx)，别等 defer；若需幂等，用client.Mutate(ctx, &mu)传CommitNow: true，避免手动管理事务生命周期
为什么 client.QueryWithVars() 返回空结果却无报错
Go 里调用 client.QueryWithVars(ctx, query, vars) 得到空 *api.Response 或 resp.Json == nil，常见原因不是查询语法错，而是变量类型不匹配或 GraphQL+- 中字段名大小写/下划线规则没对齐。
- 变量值必须是 JSON 可序列化类型：
map[string]interface{}里 key 必须小驼峰或全小写，不能含大写字母（Dgraph 默认转成小写处理）；"UserID"→"userid"才能被$userid捕获 - 查询字符串里的字段名必须与 schema 定义完全一致：schema 写的是
full_name: string @index(term)，查询就得用full_name，不能写成fullName或Full_Name - 调试时加一行：
log.Printf("query: %s, vars: %+v", query, vars)，再拿这个 query+vars 去 Dgraph UI 的 Ratel 手动执行，对比返回——Go 客户端不会透出解析级错误，UI 会明确提示variable $x not found或field y not defined
事务冲突时 txn.Commit() 报 Aborted 怎么安全重试
Dgraph 的乐观并发控制会让高并发写同一组节点的事务大概率失败，txn.Commit() 返回 error 且 strings.Contains(err.Error(), "Aborted") 是正常现象，不是 bug。但盲目重试可能放大冲突，尤其当事务内混了读+写逻辑时。
立即学习“go语言免费学习笔记（深入）”；
- 只对纯写事务（即没调用
txn.Query()或txn.QueryWithVars()）做指数退避重试；含读操作的事务重试前必须重新client.NewTxn()，否则缓存的旧读结果会导致逻辑错乱 - 重试上限设为 3 次，每次 sleep：
time.Millisecond * (1 （即 50ms → 100ms → 200ms） - 关键业务路径上，考虑用
client.Alter(ctx, &api.Operation{Schema: "..."} )提前建好必要 index，减少查询阶段的锁竞争——比如高频按email查用户，就必须有email: string @index(exact)
Dgraph 在 Go 里不是“插上就能跑”的数据库，它的 schema 强约束、gRPC 底层行为、事务模型都要求你主动适配，而不是套用 MySQL 那套思维。最常漏掉的是 reverse edge 声明和变量命名规范，这两点一错，数据就进得去出不来。
