关键在于自动化租户识别、数据隔离与上下文传递：通过 kernel.request 事件前置提取子域名租户id，存入 tenantcontext；用 doctrine sqlfilter 全局注入 tenant_id 条件；bundle 按租户动态启用；缓存键强制包含 tenant_id。
用 Symfony 做多租户 SaaS 应用，关键不在“能不能”，而在“怎么让 tenant_id 不漏、不乱、不卡”。真正的底层设计，是把租户识别、数据隔离和上下文传递变成框架自动完成的事，而不是靠每个开发者手动加 WHERE tenant_id = ?。
租户识别必须前置且无感
不能等请求进到 Controller 才判断是谁——那太晚了。Symfony 的请求生命周期里，最佳介入点是 Kernel 请求处理早期，比如通过自定义 RequestListener 或 HTTP 内核事件（kernel.request）。
- 优先从子域名提取租户：如
acme.yoursaas.com→ tenant_id = 'acme'，配合 DNS CNAME 支持客户绑定自有域名 - 备选路径：请求头（
X-Tenant-ID）或路由前缀（/t/{tenant}/dashboard），但需在安全网关层校验合法性，避免伪造 - 识别结果必须存入
ThreadLocal-风格的容器（Symfony 中常用RequestStack+ 自定义TenantContext服务），确保后续任意层级（Service、Repository、Doctrine Listener）都能安全读取
数据隔离不能依赖人工写 SQL
靠程序员每次写 DQL/SQL 都记得加 tenant_id 是高危操作。正确做法是把隔离逻辑下沉到数据访问层：
- 用 Doctrine 的
SQLFilter全局启用租户过滤：定义一个TenantFilter，对所有含tenant_id字段的实体自动注入WHERE tenant_id = :tenant_id条件 - 配合
TenantContext动态绑定参数，无需修改任何 Repository 方法 - 对跨租户管理类操作（如后台审计、系统管理员查看全量数据），提供临时绕过 Filter 的显式 API（如
disableTenantFilter()），并强制日志留痕
Symfony Bundle 是租户能力的组织单元
不同租户可能需要启用不同功能模块（比如 A 客户要发票功能，B 客户不需要），Bundle 天然适合做这种可插拔的能力封装：
- 为每类租户能力建独立 Bundle（
InvoicingBundle、AnalyticsBundle），在config/packages/下按租户配置启用 - 利用 Symfony 的
Kernel::configureContainer()或环境变量动态加载 Bundle，例如：if ($tenant->hasFeature('invoicing')) { $container->registerExtension(new InvoicingExtension()); } - 结合
feature flag组件（如symfony/feature-toggle）实现运行时开关，避免重启服务
缓存与租户上下文必须绑定
缓存键如果不带租户维度，就会出现 A 租户看到 B 租户的数据——这是典型缓存污染。
- 所有缓存 Key 必须包含
tenant_id，推荐格式：tenant:{id}:user:list:page_1 - 使用
cache.app时，在生成 Key 前统一拼接租户前缀；若用 Redis，可直接用命名空间（tenant:acme:user:list） - 清除缓存也要租户粒度：提供
bin/console saas:cache:clear --tenant=acme命令，内部调用$cache->deleteItems(...)并限定前缀
