symfony 7 的依赖注入标签是服务注册时显式声明的能力标识符，用于触发容器编译期特定逻辑，必须在配置中显式定义，不可自动推断或通过注释/类属性声明。
Symfony 7 的依赖注入标签（tags）不是装饰器或元数据标记，而是服务注册时显式声明的「能力标识符」，用于触发容器在编译期执行特定逻辑 —— 比如自动收集监听器、注册命令、挂载验证约束。漏掉或写错 tags，服务就进不了对应机制的处理流水线。
service tags 必须显式声明，不会自动推断
自动装配能解决构造函数参数注入，但无法替代 tags。比如你写了一个 EventListener 类，即使它实现了 EventSubscriberInterface，若没在服务定义里加 kernel.event_listener 标签，它就不会被事件分发器识别。
-
tags是服务定义的一部分，必须出现在 YAML/XML/PHP 配置中，或通过#[AsEventListener]等属性显式标注 - 常见错误：把
tags写成类属性或注释，容器完全忽略 - Symfony 7 不再支持隐式标签推导（如旧版根据接口名自动打 tag），所有 tag 都需人工声明
- YAML 示例：
App\EventListener\UserRegisteredListener: tags: ['kernel.event_listener' => ['event' => 'app.user_registered']]
常用 tag 及其 required attributes 不能省略
很多 tag 要求带特定键值对，缺一不可，否则编译失败或行为异常。例如 console.command 必须有 command 属性，validator.constraint_validator 必须指定 constraint。
-
kernel.event_listener：至少要指定event或event+method；若用priority，值必须是整数 -
console.command：command是必需字段，如'command' => 'app:sync-users' -
messenger.message_handler：必须匹配所消费消息类的完整命名空间，如'handles' => 'App\Message\SendEmailMessage' -
doctrine.orm.entity_listener：需指定entity和event，且entity必须是已映射的实体类名
自定义 tag 的编译期处理逻辑必须注册
你加了 myapp.cache_warmer 这样的 tag，不代表 Symfony 就会调用它 —— 容器不知道这个 tag 对应什么行为，除非你在扩展类里显式注册处理器。
- 自定义 tag 需配合
CompilerPassInterface实现，在process()方法中遍历带该 tag 的服务并注册到某管理器 - 别直接在
build()中硬编码处理逻辑：它发生在配置加载前，服务还未全部定义 - 示例场景：收集所有
app.exporter服务，注入到一个ExporterRegistry中 —— 这个 registry 本身也得是容器服务，且不能被标记为private: true（否则无法被 compiler pass 访问）
tag 冲突与覆盖规则容易被忽略
同一个服务可以打多个 tag，但某些 tag 存在互斥性。例如，一个服务同时标了 kernel.event_listener 和 kernel.event_subscriber，后者会被忽略 —— 因为 Subscriber 机制是在编译期扫描类实现的接口，而 Listener 是靠 tag 显式注册的，两者走不同路径。
-
kernel.event_subscriber不需要手动打 tag，只要类实现EventSubscriberInterface并被自动装配即可 - 多个相同 tag 的服务，优先级由
priority决定；未设 priority 默认为 0，同 priority 下顺序不确定 - 若服务在多个配置文件中被重复定义（如 bundle 配置 + 项目 config），后加载的配置会覆盖前者的
tags，不是合并
真正难调试的不是 tag 写不写，而是它有没有被某个 compiler pass 捕获、有没有被正确传入目标系统。建议运行 php bin/console debug:container --tag=xxx 直接验证服务是否已按预期注册，比翻日志快得多。
