Dgraph中直接用has/uid查角色关联出错，因未声明@reverse边且Go客户端不自动展开反向引用；需在schema中定义roles:[uid]@reverse，并用嵌套query或~roles查询。
为什么直接用 Dgraph 的 has 和 uid 查角色关联会出错
Go 客户端调用 Dgraph 时，如果直接按关系字段名（比如 roles）查，常返回空或 panic —— 因为 Dgraph 不存“外键字段”，只存反向边（reverse edge）或通过 ~roles 查询。你写的 roles 是正向边，但 Go 客户端默认不自动展开反向引用。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 定义 schema 时必须显式声明反向边：
roles: [uid] @reverse .，否则~roles查不到任何东西 - 在 Go 中查询用户带角色，要用两级 query：先查用户 UID，再用
uid值拼~roles子查询，或用嵌套 query（推荐） - 别依赖
json.Unmarshal直接映射到含 slice 字段的 struct——Dgraph 返回的uid是字符串数组，不是嵌套对象；得手动解析result.Uids或用dgo的Node解析逻辑
Go 里怎么写一个能查“用户→角色→权限”的嵌套 query
Dgraph 支持递归嵌套查询，但 Go 客户端 dgo 的 Query 方法只接受 raw string，没法自动拼参数。容易漏掉 var 声明或 expand(_all_) 导致权限字段为空。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
fmt.Sprintf拼 query，确保变量名统一（如$a），并在 query 开头加var $a := ... - 角色到权限需再嵌一层：角色节点上要有
permissions: [uid]边，且 schema 中声明permissions: [uid] @reverse . - 示例 query 片段：
var $user := { user(func: eq(name, "%s")) { uid } }; user(func: uid($user)) { name roles @facets { type } ~roles { name permissions @facets { level } ~permissions { name } } } - Go 中执行后，从
resp.Json解析成 map[string]interface{}，再逐层取["user"][0]["roles"]、["~roles"]等 key——Dgraph 返回的是扁平化结构，不是树形
微服务间如何安全传递角色上下文而不暴露 Dgraph UID
把原始 uid（如 0x12345）直接透传给下游服务，既不安全也不可读。JWT 里塞 raw UID 还可能被篡改，且下游没权限查 Dgraph。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 在认证服务生成 token 时，只存角色名（
role_name）和有效期，**不存 UID**；角色名从 Dgraph 查询结果中提取name字段 - 下游服务校验 token 后，用
role_name查本地缓存（如 map[string][]string）获取对应权限列表——缓存由定时 job 或变更 hook 更新 - 若必须实时查，下游应走独立的 Dgraph 只读 client，用
eq(name, "...")查角色，再查其permissions，**不要复用上游的 UID** - 避免在 HTTP header 里传
X-Role-Uid这种字段——UID 不是业务标识，也不稳定（删重建可能变）
用 dgo 批量写角色关联时为什么超时或丢数据
dgo 默认单次 Mutate 限制 1MB，而批量绑用户→角色时，每条边都是独立 set，很容易触发 rpc error: code = ResourceExhausted desc = grpc: received message larger than max...。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 拆分 mutate：每批 ≤ 100 条边，用
txn.Mutate分多次提交，别堆一起 - 用
set而非delete+set清旧关——Dgraph 的delete不支持边级粒度，删整个节点太重 - 写失败时检查
err是否含"predicate not found"——说明 schema 没提前 apply，得先跑dgraph live --schema=... - 日志里打印
len(mutation.Set)和len(mutation.Delete)，确认没误把空 slice 当有效 mutation 提交
真正麻烦的不是语法，是 Dgraph 的边模型和 Go 的静态类型之间那层薄但关键的映射——每次写 query 前，先用 Ratel 控制台手敲一遍，确认返回结构和你代码里 expect 的一致，比补 debug 日志快得多。
