必须关闭debug、预热缓存、用redis替代文件缓存，并为translation和di容器单独调优；cache.adapter.redis_tag_aware是symfony 8默认推荐驱动，支持按标签批量清除，避免全量刷新。
缓存没配对，性能优化就是空谈。Symfony 的性能瓶颈往往不出在业务逻辑，而出在缓存策略错配或未启用关键缓存层。直接上结论：生产环境必须关闭 debug、预热缓存、用 Redis 替代文件缓存，并为 Translation 和 DI 容器单独调优。
cache.adapter.redis_tag_aware 是 Symfony 8 默认推荐的缓存驱动
它不是“可选”，而是解决高频更新场景下缓存失效问题的核心机制——支持按标签批量清除，避免全量刷新。
- 配置时必须指定
default_redis_provider，否则会 fallback 到cache.adapter.php_array（内存数组），重启即丢 - 若用哨兵模式，连接字符串要写成
redis://sentinel:26379?service_name=mymaster，不能只填 IP - 不建议混用
cache.adapter.redis和cache.adapter.redis_tag_aware：前者不支持标签，后者底层依赖 Redis 的SCAN和DEL命令，需确保 Redis 版本 ≥ 6.0 - 标签名别硬编码，用
TagAwareAdapter::invalidateTags(['user', 'profile'])比cache:pool:clear更精准
Translator 缓存必须脱离文件系统
默认的 FilesystemAdapter 在多实例部署下会导致翻译不一致，且每次请求都要 stat 文件、反序列化 PHP 数组，I/O 开销显著。
- 不要试图 patch
Translator构造函数传入自定义 cacheDir；应改用TranslationCacheWarmer+ 自定义ProviderInterface实现 Redis 写入 - 缓存 key 命名需包含 locale + domain + cacheVary（如哈希后的上下文变量），否则不同语言包可能互相覆盖
- Redis 中建议用
SET存储 catalogue 元数据，用HASH存翻译条目，便于按 domain 查询 - 若用集群，注意
getCatalogueCachePath()生成的文件名含 base64 hash，但 Redis 不认路径分隔符，需统一转义为下划线
服务容器编译缓存和路由缓存必须预热
即使开了 APP_ENV=prod，首次请求仍会触发编译，造成“冷启动延迟”。这不是 bug，是设计行为，但可以规避。
- 执行
cache:warmup --env=prod后，var/cache/prod/srcApp_KernelProdContainer.php和var/cache/prod/routing.php才真正生效 - Docker 镜像构建阶段就要运行 warmup，否则每次容器启动都重新编译——尤其路由数量 > 100 时，匹配耗时从 3ms 跳到 12ms（见 Symfony 8 vs 6.4 对比）
- 检查
srcApp_KernelProdContainer.php是否含大量new实例化代码：若有，说明服务未设为 lazy，正在拖慢容器加载 - 路由缓存文件
routing.php是纯数组，但若用了注解路由且未加@Route的 class 有继承链，可能触发反射开销，优先改用 YAML 或 PHP 配置
HTTP 缓存头和 ESI 不是可选项，而是 CDN 协同前提
光靠后端缓存无法释放边缘节点压力。不设 max-age 或漏掉 s-maxage，CDN 就不会缓存，所有请求都打到应用层。
-
$response->setPublic()必须配合setMaxAge()，否则代理认为不可缓存 - ESI 片段的响应必须带
X-Symfony-ESI: 1header，且主响应要设Vary: X-Symfony-ESI，否则 Varnish 会合并缓存 -
@Cache注解在控制器方法上有效，但在服务类里无效——它只影响 Response 生命周期，不控制数据缓存 - 动态内容（如用户昵称）不能进 ESI，要用
esi:include+nocache属性，否则缓存污染
最易被忽略的点：缓存适配器的 provider 配置错误时，Symfony 不报错，而是静默降级为内存数组缓存。查 cache:pool:stats 输出里的 driver 字段，确认是 redis 而非 array ——这是线上性能是否真实提升的唯一可信指标。
