最可靠的方式是用http.Client调用本地OPA实例的/v1/data接口，而非嵌入rego SDK；需严格对齐input结构、设置5秒超时、只依赖response.result字段，并预留bundle更新与decision log等扩展配置。

Go 服务集成 OPA 最可靠的方式是用 opa/rego SDK 调用本地 OPA 实例（HTTP），而不是直接嵌入 Rego 解释器——后者缺乏策略热加载、版本管理与调试能力，生产环境几乎不用。

用 http.Client 调用 OPA 的 /v1/data 接口是最常用且稳定的集成方式

OPA 默认以独立服务运行（opa run --server），Go 程序只需发 POST 请求到 http://localhost:8181/v1/data 即可评估策略。这种方式解耦清晰，策略变更无需重启 Go 服务。

• 请求 body 必须是 JSON，包含 input 字段（策略逻辑依赖的上下文）和可选的 path（对应 Rego 中的 package 路径，如 authz.allow）
• 响应结构固定：{"result": true/false/object}，不要依赖 status 字段判断结果，只看 result
• 务必设置超时：http.Client{Timeout: 5 * time.Second}，避免 OPA 响应慢拖垮整个请求链路
• 错误处理重点捕获三类：net/http 连接错误、400/500 HTTP 状态码、JSON 解析失败——它们对应不同问题层级

opa/rego 包不适用于生产策略执行，仅适合单元测试或离线验证

官方 github.com/open-policy-agent/opa/rego 包能加载 Rego 模块并在内存中执行，但实际项目里极少用它做运行时策略决策。

Go语言（Golang）1.26.0

Go语言（Golang）1.26.0版本官方下载，版本号 1.26.0，适合旧项目维护、兼容性测试和指定版本开发环境搭建。

下载

• 无法热更新策略：每次改 .rego 文件都要重建 Go 二进制或手动 reload 模块，违背 OPA 的核心设计目标
• 缺少策略元数据支持：比如 no decision_logs、no bundle 下载、no metrics 上报路径
• 调试困难：HTTP 模式下可用 curl -X POST localhost:8181/v1/data?pretty 直接复现请求；而嵌入模式需写额外日志或断点
• 例外场景：仅在 CI 流程中验证 Rego 语法、或为 handler 写单元测试时 mock rego.PrepareForEval()

输入结构必须与 Rego 中的 input 定义严格对齐，否则策略永远返回 undefined

Rego 不做自动类型转换，input.user.id 是字符串，但 Go 发送的是整数 ID，策略就会静默失败（result 为 null）。

• 推荐定义 Go struct 显式映射 input，例如：

  type AuthzInput struct {
      User struct {
          ID   string `json:"id"`
          Role string `json:"role"`
      } `json:"user"`
      Resource struct {
          Type string `json:"type"`
          ID   string `json:"id"`
      } `json:"resource"`
  }

• 避免用 map[string]interface{} 构造 input：字段名大小写、嵌套层级、空值处理极易出错
• 如果 Rego 使用了 input.method == "POST" 这类硬编码判断，确保 Go 侧传的 method 是全大写字符串，而非 http.MethodPost 常量

真正麻烦的不是第一次调通接口，而是当策略开始分 bundle、加 decision log、配 status webhook 后，Go 侧没预留好配置入口或重试逻辑——这些扩展点在初期集成时就得想清楚。