迁移至Cloud NDB：请求级命名空间安全切换及性能优化问询

你完全戳中了问题的要害——直接修改全局client的namespace属性确实不是线程安全的，这会导致多请求并发时命名空间互相覆盖，进而出现用户数据串流的严重问题。而且你的疑惑非常正确：命名空间本质上应该是上下文（Context）的属性，而非Client的属性，这也是Cloud NDB设计的初衷。

为什么你的原有实现有风险？ #

全局的ndb.Client()实例是跨请求共享的，它主要负责管理连接池等全局资源，并不存储请求级别的状态。当你在switch_user里修改client.namespace时，这个修改会被所有并发的请求看到——比如请求A刚把命名空间改成client_a，请求B紧接着改成client_b，这时候请求A后续的数据库操作就会跑到client_b的命名空间里，直接导致数据泄露或错乱。

正确的实现方式：将命名空间绑定到请求级上下文 #

Cloud NDB的Context是请求/操作级别的隔离单元，每个请求的上下文完全独立，不会互相干扰。我们只需要在每个请求创建上下文时，直接指定对应的命名空间即可，不需要修改全局Client的属性。

1. 调整WSGI中间件，在上下文初始化时指定命名空间

保留全局Client实例（它是线程安全的，复用连接池能减少开销），在中间件里解析请求的邮箱、确定命名空间，然后传入context()方法：

from google.cloud import ndb

client = ndb.Client()

def ndb_wsgi_middleware(wsgi_app):
    def middleware(environ, start_response):
        # 从请求中解析用户邮箱（这里需要你实现自己的解析逻辑，比如从headers/token中提取）
        email = extract_email_from_request(environ)
        # 确定该用户对应的命名空间
        namespace = determine_namespace(email)
        
        # 创建带有指定命名空间的上下文，所有请求内的NDB操作都会在这个命名空间下执行
        with client.context(namespace=namespace):
            return wsgi_app(environ, start_response)
    return middleware

2. 临时切换命名空间的正确姿势

如果你的业务需要在单个请求内临时切换到其他命名空间（比如跨客户的批量操作），不要直接修改Client或全局上下文，而是使用Context.set_namespace()上下文管理器，确保操作在隔离的命名空间内执行：

def cross_client_operation(target_namespace):
    # 获取当前请求的上下文
    current_context = ndb.get_context()
    # 临时切换到目标命名空间，with块内的操作都在该命名空间下
    with current_context.set_namespace(target_namespace):
        # 示例：查询目标命名空间下的数据
        results = MyNDBModel.query().fetch()
        # 处理逻辑...

关于Client创建开销的补充 #

你担心把Client创建移到中间件会产生大量开销，这个顾虑是对的——但其实完全不需要这么做。全局的ndb.Client()实例是轻量级且线程安全的，它会自动管理连接池，复用已有的连接。我们只需要复用这个全局实例，在每个请求的上下文里指定命名空间即可，既安全又高效。

总结 #

• 永远不要修改全局ndb.Client()的namespace属性，它是共享资源，会引发竞态条件
• 命名空间是请求级上下文的属性，通过client.context(namespace=xxx)绑定到每个请求
• 临时切换命名空间使用context.set_namespace()的上下文管理器，确保操作隔离

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