嵌入式 opa 通过 rego.preparedevalquery 替代 http 调用，降低延迟并提升可控性，但需手动处理策略热加载、并发安全、输入结构匹配、错误降级及内存优化等关键问题。
直接嵌入 rego 查询比调用 HTTP 接口更可控、延迟更低，但必须手动处理策略热加载和并发安全——这是最容易被跳过的关键点。
嵌入式 OPA：用 rego.PreparedEvalQuery 替代 HTTP 调用
微服务对授权延迟敏感（尤其在 API 网关或鉴权中间件中），HTTP 调用 OPA 服务会引入网络抖动、超时、重试逻辑。嵌入式方式把策略引擎直接跑在 Go 进程内，避免额外 hop。
-
rego.New().Compile()+.PrepareForEval()是标准路径，PreparedEvalQuery实例可复用，但不是 goroutine-safe —— 必须每次Eval()都传新context，且不能跨协程共享同一实例 - 策略文件需在启动时读取并编译；若从文件系统加载，要监听
fsnotify事件触发重新Compile()，否则改了.rego文件不生效 - 不要在
Eval()前做 deep copy input map：OPA 内部会 shallow-copy，但若 input 含指针或非基本类型（如time.Time），需确保其可序列化为 JSON（Rego 只认 JSON 兼容结构）
input 结构设计：字段名必须与 Rego 中 input.xxx 完全一致
Rego 是严格基于字段名匹配的，大小写、下划线、嵌套层级都不能错。常见错误是 Go struct 字段 tag 写成 json:"user_id"，但 Rego 里写 input.subject.userId，结果 userId 永远为空。
- 推荐用
map[string]interface{}构造 input，避免 struct tag 错配；例如："subject": map[string]interface{}{"user": c.Query("user"), "groups": c.QueryArray("groups")} - 环境属性（如时间、IP）建议统一塞进
input.env下，避免策略里散落input.time、input.ip等扁平字段，后续扩展难 - 若 input 数据量大（如含完整 JWT payload 或 RBAC 角色列表），注意 Rego
eval是单线程执行，复杂规则可能卡住整个 goroutine —— 可加context.WithTimeout限定 50ms
策略加载失败时的静默降级风险
OPA SDK 默认在 Compile() 失败时 panic，但生产环境应捕获并 fallback 到默认拒绝（allow = false），否则服务启动就挂。
- 检查错误类型：
if errors.Is(err, rego.ErrCompile)，而非用strings.Contains(err.Error(), "syntax")—— 后者不可靠且易漏报 - 编译失败后，保留旧的
*rego.PreparedEvalQuery实例继续服务，同时打 error 日志并告警；不要 reload 时清空旧实例再 load 新的，否则窗口期无策略 - 本地开发可用
opa test预检 Rego 语法，但 CI 中必须跑go test加载真实策略文件验证，因为opa test不校验 Go 侧 input 结构是否匹配
并发与内存：别让 rego 成为 GC 压力源
每次 Eval() 都会分配临时 AST 节点和缓存 map，高 QPS 下易触发频繁 GC。这不是理论问题，压测 2k RPS 就能观察到 runtime.mallocgc 占比飙升。
- 禁用 Rego 内置缓存：
rego.EvalOption(rego.Cache(false))—— 它的 LRU 缓存 key 是 input 的 JSON 序列化结果，实际业务 input 几乎不重复，缓存命中率趋近于 0 - 复用
rego.EvalInput对象：声明为局部变量，每次只改其.Value字段，避免反复 new - 若策略逻辑简单（如纯 RBAC 判断），考虑用 Casbin 替代：它内存占用低一个数量级，且
Enforce()是纯函数无 GC 开销；OPA 优势在复杂 ABAC/多数据源 join，别为简单场景硬上
真正麻烦的从来不是第一次跑通 rego.Eval()，而是上线后某天发现策略更新了但没生效，或者凌晨三点 GC 毛刺导致超时激增——这些都藏在热加载逻辑和内存生命周期里，而不是 Rego 语法本身。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
