PrependExtension 接口的用途
解读
在国内主流框架（Symfony、Laravel 底层依赖 Symfony 容器）的面试里，面试官问 PrependExtension 并不是想听你背定义，而是考察三点：
- 是否真正写过 Bundle/组件，知道“配置合并顺序”带来的坑；
- 能否利用该接口在“用户配置”生效前，把框架自身或第三方 Bundle 的参数提前注入，从而做到“零侵入”调优；
- 是否理解容器编译期的执行链路，能在高并发、多环境（Dev/FAT/PROD）场景下给出可落地的性能或安全方案。
一句话：PrependExtension 是 Symfony 容器在编译阶段留给 Bundle 的“最后一次插队机会”，用来在最终配置冻结前，强制追加或覆盖参数，解决“用户配置可能把框架关键配置冲掉”的痛点。
知识点
- 执行时机：容器编译阶段，所有 Bundle 的 Extension 被加载后、processConfiguration 之前；因此 prepend() 里拿到的 $container 是未冻结的 ContainerBuilder。
- 接口位置：Symfony\Component\DependencyInjection\Extension\PrependExtensionInterface，只有一个方法 prepend(ContainerBuilder $container)。
- 典型用途：
- 为当前 Bundle 预注册默认配置，防止用户未写 config/packages/xxx.yaml 导致服务缺失；
- 给第三方 Bundle 注入环境变量（如数据库版本、Redis 前缀），避免用户感知；
- 在 Laravel 生态中，若自己公司封装了“内部starter-bundle”，可用 prepend 把 monolog.handler.redis 的 host/port 提前写死，禁止业务侧覆盖，方便 SRE 统一收集日志。
- 与 CompilerPass 区别：CompilerPass 发生在配置合并之后，只能操作已解析的 Definition；PrependExtension 发生在合并之前，可操作原始数组，粒度更粗、性能更好。
- 国内踩坑案例：某电商大促前夜，运维把 session.handler 的 ttl 改小，结果 config/packages/framework.yaml 里又被研发写死 86400，导致缓存雪崩；如果框架团队提前在 prepend() 里把 ttl 锁定，就不会出现“用户配置覆盖运维紧急调参”的悲剧。
答案
PrependExtension 是 Symfony 提供的一个容器编译期钩子接口。实现该接口的 Bundle 可以通过 prepend(ContainerBuilder $container) 方法，在所有用户配置生效之前，向容器注入或覆盖参数、配置数组。它的核心用途是“强制预置默认配置”，解决框架与业务、第三方 Bundle 之间的配置优先级冲突，同时避免用户误操作导致关键参数失效。在国内实际项目中，常用于：
- 统一注入数据库、Redis、链路追踪等基础设施的连接信息；
- 为 Monolog、Twig、Framework Bundle 设置性能/安全默认值；
- 在多 Bundle 协作场景下，保证公司基础 Bundle 的配置总是最后“拍板”，让业务侧“无感知”即可享受到最新调优参数。
拓展思考
- 灰度场景：如果公司采用“配置中心 + 本地文件”双写策略，可在 prepend() 里先判断 $_ENV['CONFIG_CENTER_ENABLE']，动态把远端配置合并到容器，实现“配置中心未下发时 Bundle 自带兜底”。
- 安全合规：国内金融项目要求“密码不得落地文件”，可在 prepend() 中读取 k8s Secret 注入到 doctrine.dbal.password，确保即使开发者 dump 配置也看不到明文。
- 性能调优：大流量接口常把 framework.session.storage_factory_id 换成 redis，但业务 Bundle 可能忘记配；框架团队在 prepend() 里直接改默认值，比事后在文档里写“建议”更可靠，也减少一次运行时判断。
- 与 Laravel 的打通：虽然 Laravel 没有原生 PrependExtension，但可借助 \Illuminate\Contracts\Foundation\Composer::prepend 或 package:discover 阶段的自定义脚本，模拟相同效果，实现“公司级 starter 包”对 Octane、Horizon 的默认调优，让国内大量基于 Laravel 的中台项目也能享受“编译期插队”带来的稳定性红利。