go-oidc 是必须使用的库，因 golang.org/x/oauth2 不校验 id_token；Zitadel 作为标准 OIDC Provider，需手动完成 token 校验、issuer 匹配、aud 检查等；oidc.Provider 应全局复用且带超时上下文；issuer URL 必须严格匹配部署地址；verifier 的 ClientID 和动态 issuer（多租户场景）须准确配置；nonce 校验不可跳过；会话与密钥管理需自主实现，推荐 Redis/PostgreSQL 存储 session，并支持多密钥轮换验证。
go-oidc 是必须用的库，golang.org/x/oauth2 只管换码，不验 id_token ——漏掉这步等于把门钥匙交给任何人。
Zitadel 本身是标准 OIDC Provider，但 Go 客户端必须自己完成 token 校验、issuer 匹配、aud 检查等关键步骤，否则身份真实性完全不可信。
初始化 oidc.Provider 时不能每次请求都新建
频繁调用 oidc.NewProvider 会导致 HTTP client 复用失效、DNS 重复解析、连接池耗尽，QPS 下降明显。
- 全局复用一个
*oidc.Provider实例，建议在应用启动时初始化并注入依赖 - Provider 的
ctx应带超时（如context.WithTimeout(ctx, 5*time.Second)），避免 DNS 卡死阻塞整个认证流程 - Zitadel 的 issuer URL 必须严格匹配其实际部署地址（如
https://auth.example.com），末尾不加斜杠；/.well-known/openid-configuration路径必须可公开访问（反向代理常拦截/.well-known，需显式放行）
id_token 校验必须手动做，且字段一个都不能少
Zitadel 发放的 id_token 是 JWT，Go 标准库不校验 OIDC 语义，go-oidc 会帮你做签名、exp、iss、aud、nonce（如果用了 PKCE）、azp（多客户端场景）——但前提是你要传对 verifier。
- 用
provider.Verifier(&oidc.Config{ClientID: "your-client-id"})创建 verifier，ClientID必须和 Zitadel 控制台注册的应用client_id完全一致 - 如果 Zitadel 启用了租户隔离（multi-tenancy），
iss字段会是https://auth.example.com/teams/{tenant-id}，此时 verifier 的issuer必须动态匹配，不能硬编码为根域名 - 别跳过
nonce校验——Zitadel 默认启用 PKCE，但某些前端 SDK（如@zitadel/sdk-js）可能不自动传nonce，后端得配合关掉或显式生成/验证
会话与密钥管理容易被忽略的坑
Zitadel 本身不托管你的应用会话，Go 后端要自己决定怎么存用户登录态；密钥轮换也得你主动处理。
- session 存储别用
gorilla/sessions默认内存 store，生产环境必须对接 Redis 或 PostgreSQL（Zitadel 自身就用 PG，可复用同一套） - Zitadel 的 signing key 默认是 RSA，如果你在 Go 里用
go-oidc验证，它会自动从jwks_uri拉公钥；但首次拉取失败时不会重试，建议加一层本地缓存 + 定期刷新逻辑 - 密钥轮换后，旧 token 不会立刻失效——Zitadel 支持多密钥共存，但你的 verifier 必须能同时验证多个 kid，
go-oidc/v3默认支持，旧版 v2 不支持
/.well-known、或者以为拿到 id_token 就完事了，没走完整校验链。 
