如何实现类似Stripe的线上/测试双模式账户及API令牌架构

适配现有设计的落地思路 #

• 改造knox认证逻辑：解析pub_key_/test_key_前缀时，除了提取原始token做身份校验，同时给request对象新增两个自定义属性：request.mode（值为live/test，对应当前令牌的环境类型）、request.account_id（当前令牌绑定的账户ID）。
• 新增全局请求中间件：在请求进入业务视图前，根据request.mode的值动态绑定当前请求使用的账户模型：request.account_model = TestAccount if request.mode == 'test' else LiveAccount。所有业务视图操作账户数据时，直接调用request.account_model即可，不需要每个视图单独判断环境。
• 关联业务数据如果也拆分了测试/线上表，按照同样的逻辑在中间件层统一绑定对应模型即可。

更优的架构调整方案 #

当前拆分LiveAccount和TestAccount两个独立模型的设计，后续会产生大量冗余维护成本：比如两个模型字段完全一致的场景下，每次迭代要同步修改两次字段、维护两套序列化/校验逻辑，推荐做以下优化：

• 合并两个账户模型为同一个，新增mode字段（可选值为live/test）存储环境标识，无需拆分表。
• 令牌和账户直接做外键关联，认证阶段读取令牌绑定账户的mode字段作为环境判断依据，前缀仅作为用户侧识别环境的标识，不做实际校验逻辑，避免有人篡改前缀越权访问线上数据。
• 封装自定义Model Manager统一做环境过滤，不需要每个业务视图单独写判断逻辑，示例代码如下：

from django.db import models

class AccountManager(models.Manager):
    def current_env(self, request):
        return self.get_queryset().filter(
            mode=request.mode,
            id=request.account_id
        ).first()

后续业务层直接调用Account.objects.current_env(request)即可拿到对应环境的账户数据，不会出现串环境问题。

安全注意事项 #

• 必须以令牌关联的账户/环境标识作为最终判断依据，不能仅靠令牌前缀判断环境，避免前缀被篡改导致的越权问题。
• 测试环境所有数据默认和线上环境物理/逻辑隔离，避免测试操作污染线上业务数据。

内容的提问来源于stack exchange，提问作者Alexis