先给你讲一个真实场景。企业在部署 GitHub Copilot 时，常常遇到一个棘手的实际问题：如果多个部门、不同客户都使用同一套 Copilot 服务，如何确保他们的数据不会交叉混淆？研发团队的代码补全历史、法务部门的知识库检索记录、外部客户的计费明细，一旦这些数据混在一起，后果相当严重——轻则隐私泄露，重则计费紊乱，甚至推荐代码的上下文也可能被“污染”。

因此，核心解决方案就是多租户过滤器。通俗来说，就是在每次数据库查询之前，自动注入 tenant_id 条件，而不是依赖业务代码手动拼接。那么具体怎么实现？接下来我们分别探讨 Prisma 和 TypeORM 这两种主流 ORM 框架的落地方法。

多租户过滤器在 Copilot 场景中的实际作用

我们把场景具体化。当 GitHub Copilot 作为多租户服务上线后，不同租户的数据必须做到物理或逻辑上的隔离。直接在代码中硬编码 tenant_id 显然不可取——既不安全，维护成本也高。正确的做法是：在 ORM 层建立一个全局“守门员”，让每一次数据库操作自动携带所属租户的信息，从而从根本上杜绝数据交叉风险。

在 Prisma 中配置全局租户过滤器

Prisma 的实现思路相对直接，大致分为四步：

第一步，在 schema.prisma 中，为所有需要隔离的模型添加 tenant_id 字段，并正确映射数据库列名。
第二步，扩展 Prisma Client 的 $use 中间件，拦截 findMany、findFirst 等读操作，在 where 条件中强制追加 { tenant_id: { equals: currentTenantId } }。
第三步，从请求上下文中提取 currentTenantId（例如 HTTP Header 中的 X-Tenant-ID），并透传到中间件中。这里需要特别注意：如果不进行 Header 合法性校验，攻击者可能伪造 tenant_id 绕过隔离。
第四步，对于 create、update 等写操作同样注入 tenant_id，防止租户将数据写入他人的数据表。

需要注意：Header 校验不是可选项，而是必须坚守的安全底线。

在 TypeORM 中实现动态查询拦截

TypeORM 提供了三种实现方式，可根据实际需求灵活选择：

方法一：QueryRunner 监听器
在数据库连接配置中注册 query 事件监听，通过正则匹配 SELECT 语句，自动在 WHERE 后插入 AND tenant_id = $1 参数，并将 tenant_id 值绑定到参数数组末尾。适合不想修改实体代码的场景。

方法二：自定义 Repository 基类
继承 BaseEntityRepository，重写 find、findOne 等方法，在调用父类方法前统一合并 tenant_id 条件。这种方式更加显式，也便于调试。

方法三：装饰器 + 反射元数据
使用 @TenantScoped() 装饰实体类，运行时通过 Reflect.getMetadata 获取租户字段名，在执行 QueryBuilder 之前自动注入过滤条件。代码更简洁优雅，但需要熟悉 TypeScript 的装饰器机制。

验证过滤器是否生效的若干关键检查点

完成配置后，如何确认过滤器确实在正常工作？以下检查点建议逐一执行：

• 执行一条不带 tenant_id 的原始 SQL 查询（例如 SELECT * FROM prompt_templates），确认返回结果为空。
• 在日志中捕获 Prisma 或 TypeORM 生成的最终 SQL，检查是否包含 AND tenant_id = 'xxx' 片段。
• 同时启动两个租户的会话，向同一张表插入同名 Prompt 模板，验证各自只能查询到自身插入的数据。
• 在调试模式下尝试篡改 currentTenantId 变量，观察查询结果是否随之切换——这一步能暴露租户上下文传递链路是否完整。

额外说明：最后一个检查点最容易被人忽视，却又往往是问题暴露最多的地方。上下文传递链路一旦出现断点，隔离效果便形同虚设。