Context 驱动的认证状态管理

认证的本质是状态同步

认证系统解决的不是"如何登录"，而是"如何让整个应用知道用户登录了"。

登录按钮只是触发点。真正的挑战在于：当用户在某个角落完成登录后，如何让导航栏、侧边栏、内容区、甚至后台任务都立即感知到这个变化。

这是一个状态同步问题。

传统做法是：登录成功后刷新页面。这解决了状态同步问题，但体验糟糕——页面闪烁，状态丢失，用户等待。

更好的方案是：让状态自动流动。登录组件不需要通知其他组件，其他组件自动感知状态变化。

Context 模式的核心价值

React Context 提供了一个全局状态容器。任何组件都可以订阅这个状态，状态变化时自动重新渲染。

这解决了认证系统的根本问题：状态的全局可见性和自动传播。

interface AuthContextType {
  session: Session | null      // 当前会话
  profile: UserProfile | null  // 用户资料（包含积分等）
  loading: boolean             // 加载状态
  signOut: () => Promise<void> // 登出方法
}

AuthContext 做三件事：

1. 初始化时恢复会话。应用启动时调用 supabase.auth.getSession()，如果用户之前登录过，立即恢复状态。

2. 监听认证事件。订阅 onAuthStateChange 事件，捕获所有状态变化（登录、登出、token 刷新）。

3. 同步用户数据。会话建立后，从 profiles 表获取用户资料，并通过 Supabase Realtime 订阅实时更新。

状态流动的两个关键时刻

认证状态有两个关键的变化时刻：

登录时的状态建立

用户完成 Google 登录后，Supabase Auth 会触发 SIGNED_IN 事件。AuthContext 捕获这个事件，然后：

1. 更新 session 状态（包含 JWT token 和用户元信息）
2. 从 profiles 表获取完整的用户资料
3. 建立 Realtime 订阅，监听后续变化
4. 通知所有订阅组件重新渲染

整个过程无需刷新页面。登录组件不需要手动关闭模态框，不需要通知导航栏更新，不需要触发重定向。状态自动流动到需要它的地方。

积分变化的实时更新

用户生成图片或视频时，积分会被扣除。这个扣费操作发生在后端，但前端需要立即看到积分变化。

Supabase Realtime 提供了数据库级别的订阅机制。当 profiles 表的 credits 字段更新时，前端会收到推送通知，AuthContext 自动更新 profile.credits，所有显示积分的组件同步更新。

用户不需要刷新页面，不需要手动查询余额，积分数字自动变化。

这是认证系统与业务系统深度集成的体现。认证不只是管理会话，还要管理与用户相关的所有实时状态。

双重登录模式的权衡

系统支持两种 Google 登录方式：

Google One-Tap：自动弹出的被动登录。用户没有点击任何按钮，浏览器角落自动出现登录提示。摩擦最低，但可能被用户忽略或关闭。

按钮点击登录：传统的主动登录。用户点击"Sign In with Google"按钮，打开居中的登录弹窗。需要一次额外点击，但意图明确。

两种方式的技术实现相同：都调用 Google GSI SDK，都通过 signInWithIdToken() 完成认证，都触发相同的 onAuthStateChange 事件。

区别在于触发时机和用户控制权。One-Tap 是系统主动推送，按钮点击是用户主动触发。前者降低摩擦，后者提供控制感。

从刷新页面到平滑过渡

早期实现中，登录成功后会调用 window.location.reload()。这解决了状态同步问题，但牺牲了用户体验。

问题在于：依赖页面刷新来同步状态，本质上是在逃避状态管理。

改进方案很简单：移除 window.location.reload()，完全依赖 onAuthStateChange 事件驱动状态更新。

这要求更严格的状态管理：

1. 会话状态必须可靠。session 变化必须触发所有依赖组件更新。
2. 用户资料必须及时获取。登录后立即拉取 profile 数据，不能有延迟。
3. 模态框必须响应状态。登录成功后，模态框应该监听 session 变化并自动关闭。

这些要求不复杂，但需要明确的状态依赖关系。每个组件都应该声明它依赖哪些状态，状态变化时自动重新渲染。

积分系统的统一与简化

早期设计中，系统有两种积分：credits 和 video_credits。图片生成消耗 credits，视频生成消耗 video_credits。

这带来了混乱：

• 用户不理解为什么有两种积分
• 界面需要同时显示两个数字
• 扣费逻辑需要判断使用哪种积分
• 充值时需要决定充值哪种积分

简化方案是：合并为单一 credits。所有 AI 生成功能（图片、视频、未来的音频、3D）都消耗同一个积分池。

这不只是数据库列的删除，而是认知负担的减少。用户只需要关心一个数字，开发者只需要维护一套逻辑。

安全性的权衡

认证系统的安全性取决于三个层面：

Token 管理。JWT token 应该存储在 HttpOnly Cookies 中，防止 XSS 攻击窃取 token。Supabase Auth 默认使用这种方式。

会话过期。Token 有固定的有效期，过期后需要刷新或重新登录。onAuthStateChange 会捕获 TOKEN_REFRESHED 事件，自动完成续期。

敏感操作验证。即使用户已登录，某些敏感操作（修改密码、删除账号、大额扣费）仍应要求二次验证。

安全性和便利性是对立的。过短的 token 有效期提高安全性，但增加了刷新频率。过严格的二次验证保护用户，但增加了操作摩擦。

权衡的原则是：根据操作的风险等级动态调整验证强度。

查看积分余额不需要二次验证，但充值积分应该需要。生成一张图片不需要二次验证，但批量生成100张应该需要。

最后

认证系统的设计目标不是"功能完整"，而是"状态可靠"。

登录方式可以增加，支付方式可以扩展，但状态同步机制必须稳定。整个应用都依赖 AuthContext 提供的状态，任何不一致都会导致用户体验异常。

Context 模式提供了一个简单但强大的解决方案：把状态放在一个地方，让需要它的组件自己来取。

这不是最高效的方案（全局状态会导致不必要的重渲染），但它是最可靠的方案。可靠性优先于性能，除非性能问题已经明显到无法接受。

认证是基础设施，不是炫技的地方。