本技能用于将 CometChat React v7 集成从开发环境迁移到生产环境，适用于上线、安全审查或判断“是否可以安全发布”的场景。其基准为 @cometchat/chat-uikit-react@7，登录与 auth-token API 从文档获取，REST auth-token 端点位于 {DOCS_BASE}/rest-api/auth-tokens。资料说明 React UI Kit 文档没有单一的生产加固页面，本清单属于该技能包依据 RULES.md §4（凭据）及套件实际内容给出的自有指导，并标注为文档缺口。
配套技能（建议先读）：cometchat-react-v7-core 覆盖开发凭据流程与 init→login→render 顺序；cometchat-react-v7-patterns 覆盖各打包器的环境变量前缀与构建细节；cometchat-security 覆盖企业认证模型，包括将 IdP/SSO 接入 token 流程、token 过期/刷新与重新登录、RBAC 角色与群组（SBAC）范围，以及 Auth Key、auth token 与 REST API Key 的区别。
核心要点：绝不能在浏览器包中发布 Auth Key。Auth Key 可为应用内任意用户签发会话，任何带 VITE_/NEXT_PUBLIC_/REACT_APP_/PUBLIC_ 前缀的值都会被编译进用户下载的 JavaScript，因此放在其中的 Auth Key 等同于公开，任何人都能读取、以任意 UID 登录并读取所有会话。
生产登录流程：1）应用先完成自身用户认证（CometChat 不是身份提供方）；2）服务器使用 REST API Key 调用 CometChat REST API，为该用户 UID 签发 auth token；3）服务器通过已认证请求把 token 返回浏览器；4）应用调用 loginWithAuthToken(token)。示例代码：const res = await fetch("/api/cometchat-token", { credentials: "include" }); const { authToken } = await res.json(); await CometChatUIKit.loginWithAuthToken(authToken);。UID 必须来自服务端会话，绝不能接受 ?uid= 或任何客户端提供的 UID，否则可被冒充。
环境变量前缀：开发时 init 从客户端环境读取 Auth Key，生产必须将其置空并改用 token 登录。前缀因打包器而异：Vite 用 VITE_，Next 用 NEXT_PUBLIC_（.env.local），CRA 用 REACT_APP_，Astro 用 PUBLIC_。App ID 与 Region 不是机密，Auth Key 才是机密。可用以下命令检查构建产物：npm run build && grep -rll "<your-auth-key>" dist/ build/ .next/ 2>/dev/null && echo "LEAK" || echo "clean"，并建议在 CI 中运行。
上线前其他事项：用户应在服务端随注册流程创建，而非浏览器端（客户端代码中不得用 Auth Key 调用 createUser）；正确登出：await CometChatUIKit.logout()，然后清理派生的 React 状态并注销推送 token；全程 HTTPS（通话 getUserMedia 与推送需要）；将套件版本锁定为精确或 ~ 范围；用 CometChatErrorBoundary 包裹界面以显示回退而非白屏（它不是初始化器，init/login 仍需先运行）；SSR/StrictMode 下需防护 init+login，避免 React 18/19 StrictMode 双调用导致两次登录竞争，且绝不在 SSR 期间 init，需在客户端门控；Region 必须在每个构建中与仪表盘应用一致；在生产应用（而非仅开发应用）启用仪表盘扩展/AI。
上线前检查清单：生产包中无 Auth Key（CI 中 grep 验证）；生产使用 loginWithAuthToken，UID 来自服务端会话；REST API Key 仅服务端；使用正确的打包器环境变量前缀，.env 已加入 gitignore；HTTPS 与有效证书；登出清理会话、React 状态与推送 token；套件版本已锁定，CometChatErrorBoundary 就位；生产应用已启用仪表盘扩展/AI；已用生产应用凭据测试。
常见陷阱：生产包中出现 Auth Key（最关键，通常由错误的环境变量前缀导致）；token 端点信任客户端提供的 UID（导致冒充）；SSR 期间或 StrictMode 下 init/login 运行两次（竞争与“已登录”错误）；仅在开发应用配置仪表盘（生产功能静默缺失）；没有登出清理（下一个用户继承会话或推送 token）。
验证方式：生产构建不含 Auth Key（grep）；通过 token 登录成功；被篡改的 UID 被服务器拒绝；登出完全清理；通话与推送在 HTTPS 下工作；生产应用已启用相关功能。