嵌入式调用性能最优，qps提升3–5倍，因省去网络往返和序列化开销；但需手动实现策略热更新，且输入json字段名必须与rego中input严格匹配，否则导致undefined；并发下须避免复用非goroutine-safe的rego.query，应缓存rego.rego实例并按需生成新query。
直接嵌入 github.com/open-policy-agent/opa Go SDK 是最可控、延迟最低的方案，适合对性能敏感且策略变更不频繁的微服务；HTTP 调用更适合策略高频更新、多服务共享策略的场景，但引入网络开销和故障点。
为什么选嵌入式调用而不是 HTTP？
嵌入式调用把 OPA 编译进二进制，省去网络往返和序列化开销，实测 QPS 提升 3–5 倍（尤其在 JWT 解析后立刻鉴权的链路中）。但它要求策略文件随服务发布，热更新需额外实现文件监听 + rego.Compile + compiler.Compile 重建模块。HTTP 方式虽方便策略独立部署，但单次鉴权多出 20–100ms 网络延迟，且 opa run --server 默认不启用 TLS 和认证，暴露在内网也需加一层代理或 mTLS 保护。
如何加载 Rego 策略并执行评估？
关键不是“写完策略就完事”，而是确保输入结构与 Rego 中 input 字段严格匹配。常见错误是 Go 结构体字段名首字母大写导致 JSON 序列化后变成 UserId，而 Rego 里写的却是 user_id，结果 input.user_id 为 null，整个策略返回 undefined。
- 用
json.Marshal手动序列化输入前，先检查字段 tag：type Input struct { UserID string `json:"user_id"` } - 加载策略时优先用
rego.Load读取本地文件，避免硬编码字符串；若从 embed.FS 加载，注意路径前缀是否带./ - 执行
query.Eval后必须检查result.Error和len(result.Expressions)，空结果不等于 false —— 它可能只是策略没命中，而非明确拒绝
怎样避免并发场景下的 panic？
rego.PrepareForEval 返回的 *rego.Query 实例不是 goroutine-safe 的，直接在多个 goroutine 中复用会触发 data race 或 panic。正确做法是：每个请求新建一次 query.Eval 调用，或提前构建好 rego.Rego 实例并缓存其 Compile 后的模块，再在 handler 中按需生成新 query。
- 别在全局变量里存
query，只缓存*rego.Rego和编译后的compiler.Compiler - 如果策略逻辑复杂（如嵌套
some+count），建议用rego.Partial预编译，减少 runtime 开销 - 对高并发服务，限制单次输入大小（如
len(inputJSON) ），防止恶意构造超长 JSON 导致 OPA 内存暴涨
策略热更新要不要自己做？
OPA Go SDK 本身不提供文件监听 + 自动 reload，得自己补。但别一上来就上 fsnotify 监听整个目录 —— 容易因编辑器临时文件（如 .policy.rego~）触发重复加载。更稳妥的做法是：用 os.Stat 定期轮询策略文件 Mtime，仅当修改时间变化才重新 rego.Load + rego.Compile，并用 sync.RWMutex 保护新旧模块切换。
- 切换瞬间必须保证原子性：先 new 模块，再 swap 指针，最后 close 旧模块（如有资源需释放）
- 上线前务必测试“策略语法错误”场景 —— 错误的 Rego 会导致
rego.Compile返回非 nil error，此时不能 fallback 到旧策略，而应拒绝所有请求（fail-closed） - 别忽略日志：每次策略加载成功/失败都打一条 structured log，包含文件名、SHA256、timestamp，方便回溯
真正难的不是第一次跑通 rego.Eval，而是让策略变更不中断服务、错误输入不拖垮进程、并发压测时不 panic —— 这些边界情况往往在灰度期才暴露。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
