Bundle是Symfony中可加载、可配置、可启停的运行时单元，必须继承Bundle基类并实现生命周期方法；它不是普通目录、命名空间别名或黑盒插件，未注册、未配置则不参与请求处理。
Bundle 是什么，不是什么
Bundle 不是简单的目录或命名空间别名，它是 Symfony 中可加载、可配置、可启用/禁用的运行时单元。一个 Bundle 必须继承 SymfonyComponentHttpKernelBundleBundle，并实现生命周期方法（如 build()、getContainerExtension()）。它也不是“插件”那种黑盒式扩展——你得主动注册、配置、注入依赖，否则它不会参与请求处理链。
常见误解：把 src/Module/UserModule 这种目录直接当 Bundle 用。错。没继承 Bundle 类、没在 config/bundles.php 里声明、没定义 Resources/config/ 下的路由或服务，它就只是普通代码，不会被容器识别，也不受 Symfony 生命周期管理。
如何正确创建并启用自定义 Bundle
手动创建容易漏掉关键环节，推荐用官方命令起步，再按需调整：
- 运行
php bin/console make:bundle Module/CommentModule，生成基础结构 - 检查
config/bundles.php是否自动添加了ModuleCommentModuleCommentModule::class => ['all' => true] - 确认
CommentModule类中build()方法是否调用$container->addCompilerPass(...)（如有需要） - 若 Bundle 需提供配置，必须实现
getContainerExtension()并返回自定义Extension类 - 不要把实体类（
Entity/Comment.php）放在 Bundle 外部引用——Doctrine 默认只扫描src/Entity/；要么改doctrine.orm.mappings配置，要么把 Entity 放进 Bundle 的Entity/目录并显式注册映射
Bundle 间通信：为什么不能直接 new Service 或 use Entity
跨 Bundle 直接 new 一个服务或 use AppModuleUserModuleEntityUser 看似能跑，但会破坏模块边界和可复用性：
- 硬编码路径导致 Bundle 无法独立测试或迁移
- Bundle A 依赖 Bundle B 的具体类，等于把 B 的内部实现细节暴露给 A，B 一重构，A 就崩
- 容器无法统一管理依赖生命周期，可能造成单例失效或构造参数不一致
- 正确做法：通过接口 + 事件 + 消息总线（如 Symfony Messenger）或 DTO 传递数据
- 例如，用户登录成功后触发
UserLoggedInEvent，由 CommentModule 订阅该事件来异步发通知，而非让 CommentController 直接调用 UserModule 的UserRepository
Bundle 复用时最容易忽略的三件事
很多团队把 Bundle 打包成 Composer 包发布后，发现别人装不上或行为异常，问题往往出在这三点：
-
composer.json里没声明autoload的psr-4映射，或路径写成"Module\CommentModule\": "src/"（应为"Module\CommentModule\": "src/"对应实际目录结构，且不能漏掉末尾斜杠） - 没提供
Resources/config/services.yaml或DependencyInjection/CommentModuleExtension.php，导致服务不自动注册，使用者得手动 copy 配置 - Bundle 内部用了
kernel.project_dir或%kernel.project_dir%/templates这类全局路径，一旦被其他项目集成，模板或资源路径就错位——应改用$this->getPath()获取自身根路径
Bundle 的边界感很弱，稍不注意就从“模块”退化成“代码堆”。真正可复用的 Bundle，必须能脱离原项目单独跑通单元测试，且不依赖任何外部配置或路径假设。
