OPA不能直接用HTTP client调用rego策略，因存在序列化开销大、连接池复杂、无热更新、错误码模糊及网络依赖等瓶颈；推荐用opa-go SDK嵌入式集成，预编译策略、直传Go struct、避免JSON与网络跳转。
OpenPolicyAgent 为什么不能直接用 HTTP client 调用 rego 策略
OPA 的 opa eval 或 POST /v1/data 接口看似能直接调用，但微服务高频请求下会迅速暴露瓶颈：HTTP 序列化开销大、连接池管理复杂、策略加载不热更新、错误码模糊（比如 400 Bad Request 实际可能是 rego 语法错或 input 结构不匹配）。更关键的是，Go 服务里每次策略判断都走网络，等于把核心鉴权逻辑交给了网络延迟和 OPA 实例可用性。
推荐用 opa-go SDK 嵌入式集成而非 HTTP 调用
官方 github.com/open-policy-agent/opa/sdk 提供了内存内评估能力，策略可预编译为 *ast.Module，input 直接传 Go struct，避免 JSON 编解码和网络跳转。实操要点：
- 用
rego.New().Load()加载本地 .rego 文件（支持嵌套目录），别依赖远程 bundle——微服务重启时 bundle 下载失败会导致启动卡死 -
rego.PartialEval()仅在需要“策略推导”（如 RBAC 权限集生成）时用；普通鉴权一律走rego.Eval() - 务必对
rego.Eval()返回的rego.EvalResult做result[0].Expressions[0].Value安全取值，OPA 可能返回空 slice 或 nil Value - 策略中避免
http.send或opa.runtime()——嵌入模式下这些 builtin 不可用，会静默失败
如何让策略变更自动生效而不重启服务
OPA SDK 本身不提供热重载，需自己监听文件系统变化并重建 rego.Rego 实例。注意几个坑：
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
- 用
fsnotify监听 .rego 文件，但不要监听整个目录——OPA 编译时可能生成临时文件，触发误重载 - 新策略编译成功前，必须保留旧
rego.Rego实例继续服务，否则出现“策略空窗期” - 重构时别直接替换全局变量，用
sync.RWMutex+ 指针原子切换，否则并发调用可能 panic - 策略加载失败时记录完整 error（含
err.Error()和rego.CompileError.Errors），否则线上 debug 只能看到 “eval failed” 这种无意义提示
微服务鉴权中间件里怎么传 context-aware 的 input 数据
OPA 的 input 是纯数据结构，但 Go 微服务常需从 context.Context 提取 traceID、用户 token 解析结果、请求路径参数等。正确做法是提前在 middleware 中构造 input struct：
立即学习“go语言免费学习笔记（深入）”；
type AuthInput struct {
UserID string `json:"user_id"`
Role string `json:"role"`
Path string `json:"path"`
Method string `json:"method"`
Headers map[string][]string `json:"headers"`
Claims map[string]interface{} `json:"claims"`
}
然后用 json.Marshal 转成 interface{} 传给 rego.Eval().Input()。特别注意：time.Time 字段必须先转成 RFC3339 字符串，否则 OPA 会报 invalid type for unification；net.IP 同理要转 string。
