国内认证与支付接入方案

Supabase 边界

Supabase 适合承担 PostgreSQL、RLS、Auth、Edge Functions、Webhook/Hooks 等底座能力，但它不是中国大陆支付网关，也不会内置微信支付、支付宝、阿里云短信、腾讯云短信这一整套商用配置。

对本项目更稳妥的落位是：

Supabase Auth 可继续作为最终 JWT 用户体系目标；本地重构期先用 app_private.auth_sessions 签发 tk_ session，保证 Web/Taro 能跑通端到端流程。

POST /api/auth/sms/send：手机号验证码发送，验证码只保存 HMAC hash。
POST /api/auth/sms/verify：验证码登录，自动创建或复用 platform_users。
GET /api/auth/me：通过 Bearer token 获取当前用户。
POST /api/auth/logout：吊销迁移期 session。
POST /api/auth/oauth/wechat、/wechat-miniapp、/qq：provider 占位，已固定错误码 PROVIDER_NOT_CONFIGURED。
tenant_auth_providers：租户级公开认证配置。
sms_verification_codes：验证码审计表，不保存明文 code。
auth_login_events：登录事件审计。
app_private.auth_sessions：迁移期 session token hash。

本地默认是 AUTH_SMS_PROVIDER=mock，仅开发环境返回 debugCode。生产环境如果仍为 mock，会直接拒绝发送。

后续真实 provider：

密钥策略：

微信小程序登录应由前端传 wx.login code 到 /api/auth/oauth/wechat-miniapp，后端调用微信 code2Session 换取 openid/session_key/unionid，再落 user_identities。

微信网页 OAuth 和 QQ OAuth 也必须在后端完成 code 换 token、获取 openid/unionid、验错、账号合并和登录事件审计。旧 PocketBase hooks 中的邀请码/销售归属逻辑后续应拆到 referral feature，不继续堆在 auth 模块里。

支付不走 Supabase 内置能力。推荐继续扩展 commerce：

POST /api/commerce/orders 只负责创建订单，金额以后端套餐为准。
POST /api/commerce/payments/:provider/create 后续按 provider 创建支付参数或收银台地址。
POST /api/commerce/payments/:provider/notify 统一落 payment_events，先验签、再幂等、再更新订单和权益。
支付成功继续复用 grantSvipEntitlement，避免微信/支付宝/XPay 各写一套开通逻辑。

B 端合作商年费、服务费、服务器资源费不走学生端 orders，而是走平台账务：

支持策略：

真实接入前需要先明确微信支付、支付宝或聚合支付是否允许你们销售的题库会员形态，以及小程序端是否涉及虚拟支付限制。