用途：为 Klaviyo 企业版实现访问控制，包括 API 密钥的细粒度读写作用域、OAuth 应用授权流程，以及建立在 Klaviyo 作用域系统之上的应用级 RBAC。Klaviyo API 没有内置角色，需通过创建多个不同作用域的 API 密钥来组合最小权限访问。
主要能力：支持按作用域划分密钥，涵盖 accounts、campaigns、catalogs、coupons、data-privacy、events、flows、images、lists、metrics、profiles、segments、tags、templates、webhooks 等资源的读写控制。可映射应用角色（admin、marketer、developer、viewer、service）到权限集与对应密钥，添加权限中间件（无角色返回 401，权限不足返回 403），接入 OAuth 应用流程并最小化请求作用域，记录审计日志并对删除 profile 等破坏性操作告警。
使用方式：在 Klaviyo 后台 Settings > API Keys 创建按服务/角色划分的作用域密钥；在应用中建立 RBAC 模块（如 src/klaviyo/rbac.ts）导出 checkPermission 与 getSessionForRole；添加权限中间件（如 src/middleware/klaviyo-auth.ts）；为第三方集成配置 OAuth 授权码交换；编写审计日志模块（如 src/klaviyo/audit.ts）。示例：const reportingSession = new ApiKeySession(process.env.KLAVIYO_KEY_REPORTING!); 路由守卫如 app.post('/api/klaviyo/campaigns/send', requireKlaviyoPermission('canSendCampaigns'), campaignSendHandler)。
适用场景：需要按用户或角色控制 Klaviyo 访问的应用、第三方/市场集成、需要最小权限与审计的企业环境。
限制：Klaviyo 无内置角色，RBAC 需自行在应用层实现；需具备 API 密钥管理权限并理解 OAuth 2.0；错误处理包括 permission_denied（403，密钥缺少作用域）、OAuth code 过期（400）、令牌刷新失败（401）、角色未分配（401）。具体实现代码与完整步骤见实现演练文档。