Dgraph是分布式图数据库，非开箱即用的语义网络中间件；需通过schema设计（如显式语言标签、区分数据/对象属性）、GraphQL+-查询、TLS安全连接及受限expand路径等手段支撑语义建模。
Dgraph 不是“语义网络图库”，它是分布式图数据库，但能高效支撑语义网络建模——关键在于 schema 设计和查询方式，而不是开箱即用的“语义层”。
为什么不能直接把 Dgraph 当作语义网络中间件用
Dgraph 本身不内置 RDF/OWL 解析、推理引擎或 SPARQL 兼容层。它用的是自研的 GraphQL+- 查询语言，谓词（predicate）对应 RDF 的 property，但没有自动 triple 归一化、类型推导或本体约束校验。强行套用 RDF 模型（比如把 name、knows、type 全设为 :string）会导致索引失效、查询模糊、无法表达 rdfs:subPropertyOf 这类语义关系。
- 常见错误：把所有字段都定义成
string并加@index(term)，结果name: "Alice"和name@en: "Alice"存成两个独立值，丢失多语言上下文 - 正确做法：显式声明语言标签谓词，如
name@en: string @index(exact)、name@zh: string @index(exact)，并用@lang指令控制查询范围 - schema 中必须区分数据属性（
age: int）和对象属性（friend: uid），后者才能参与图遍历；混用会导致expand(_all_)失效
Go 客户端连接 Dgraph 的最小安全配置
默认的 grpc.Dial("localhost:9080", grpc.WithInsecure()) 只适用于本地开发。生产微服务必须启用 TLS 和重试策略，否则 Alpha 节点重启时请求会静默失败。
- 必须设置
grpc.WithTransportCredentials(credentials.NewTLS(&tls.Config{InsecureSkipVerify: false}))，证书由 Zero 节点统一签发或挂载到容器 /dgraph/tls/ 目录 - 添加超时与重试：
grpc.WithDefaultCallOptions(grpc.WaitForReady(true), grpc.MaxCallRecvMsgSize(10*1024*1024)) - 连接池要复用：每个微服务实例只初始化一个
*dgo.Dgraphclient，不要每次请求都新建grpc.Dial - 健康检查建议调用
dg.NewTxn().Query(context.Background(), "query { me(func: has(name)) { name } }", nil)，而非 ping 端口
在 Go 微服务中建模语义网络的关键 schema 写法
语义网络依赖“类型-属性-关系”三层结构，Dgraph 需靠 @reverse、@upsert 和谓词分组实现等价表达，不是简单照搬 OWL 类名。
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
立即学习“go语言免费学习笔记（深入）”；
- 实体类型用
type谓词标记：例如person: [uid] @reverse .+type: string @index(exact)，再插入时写{"uid": "_:alice", "type": "Person", "person": {"uid": "_:alice"}} - 反向关系必须显式声明：
friend: uid @reverse .才能让~friend正确回溯，否则只能单向遍历 - 多值属性（如
sameAs）要用sameAs: [uid]，不能写成sameAs: uid，否则第二次赋值会覆盖而非追加 - 避免用
@count或@facets做语义权重——它们不参与图遍历，只用于聚合；真实权重应建模为边属性，如knows @facets(time: datetime, confidence: float)
Go 里做语义查询时容易忽略的性能陷阱
Dgraph 的 expand(_all_) 看似方便，但在微服务高频调用场景下极易引发雪崩：它会递归加载所有关联谓词，包括未索引的文本字段，导致 Alpha 内存暴涨。
- 禁止在 handler 中直接用
expand(_all_) with depth=3—— 应预先定义好受限展开路径，例如expand(person) { friend { name age } } - 全文搜索（
text索引）必须配合@index(fulltext)，且字段长度超过 10KB 会触发分片截断，需提前用strings.SplitN控制输入 - 时间范围查询别用
lt()/gt()函数嵌套，改用谓词分片：把event_at: datetime @index(year)拆成event_year: int+event_month: int，查询更快更稳 - 并发查询多个 uid 时，用
dg.NewTxn().QueryWithVars批量传参，不要 for 循环调Query，否则 gRPC 流复用失效
真正难的不是连上 Dgraph，而是让 Go 服务里的业务逻辑和 Dgraph 的谓词模型对齐——比如“用户关注话题”在代码里是 FollowTopic 方法，在 Dgraph 里却要拆成 follows: uid、topic: uid、follow_time: datetime @index(day) 三个谓词，并确保 Upsert 事务原子性。这点没对齐，语义网络就只是个带点关系的 KV 库。
