参数注入是容器按需、安全、可验证地将配置值传入服务实例，核心是构造函数声明的类型必须与services.yaml中arguments显式定义严格一致。
参数注入不是“往服务里塞值”的操作，而是让容器把配置中定义的值，按需、安全、可验证地传进服务实例。核心判断标准只有一条：构造函数里声明了什么类型，services.yaml里就得明确给什么值。
构造函数注入标量参数（string/int/array）必须显式写 arguments
自动装配（autowire）对类/接口有效，但对字符串、整数、数组这类标量值完全无感。如果你的服务构造函数里有 string $uploadPath 或 array $allowedTypes，就必须在 services.yaml 中用 arguments 显式传递：
- 参数名拼错（比如写成
%app.uploadpath%而不是%app.upload_path%）会直接报错：The parameter "app.uploadpath" does not exist - 路径类参数务必用单引号包裹，避免 YAML 把反斜杠当转义：
'%kernel.project_dir%/public/uploads' - 数组参数在
parameters区块中定义为 YAML 数组，然后用['%app.allowed_types%']传入，构造函数接收为array $allowedTypes - 不要在构造函数里写
$this->uploadDir = '%app.upload_dir%'—— 这只是字面字符串，不是参数解析
依赖服务（MailerInterface、LoggerInterface 等）优先靠 autowire 自动注入
只要你的服务类构造函数用了标准类型提示，且对应服务已注册（如 mailer.default 实现了 MailerInterface），就不用手动写 arguments：
- 确保
config/services.yaml中有_defaults: { autowire: true, autoconfigure: true } - 确认服务类在
App\命名空间下，并被resource: '../src/*'扫描到 - 类型提示优先用接口（
LoggerInterface），而不是具体实现类（MonologLogger） - 多个同类型实现（如两个 logger）时，autowire 会失败，必须用
bind:指定默认项，或改用!service显式引用
Setter 注入只在必要时用 calls，别为了“看起来灵活”而滥用
setter 注入适合可选依赖、运行时可变配置（如缓存池切换、重试延迟），但它需要你主动在 YAML 中写 calls，不能靠 autowire 自动触发：
-
calls必须写在服务定义下，格式是- ['setCachePool', ['@cache.app']]，方法名和参数顺序必须严格匹配 - 方法必须是
public，且最好带类型提示（如setLogger(LoggerInterface $logger)） - 如果开启
autowire: true且 setter 类型唯一，容器也能自动调用——但这属于“锦上添花”，不是默认行为 - 别把本该构造注入的必需依赖改成 setter 注入，否则服务可能处于不完整状态
实体对象（Media、User 等）绝对不能当构造参数注入
Doctrine 实体不是容器管理的服务，没有生命周期、不复用、不单例。试图在构造函数里写 Media $media 会导致容器启动失败或运行时报错：
- 正确做法是把实体作为业务方法的参数传入，例如
public function processMedia(Media $media): void - 若需预设关联（如表单绑定当前
Offre），应在控制器中通过 ParamConverter 获取后，再调用服务方法传入 - 实体字段的初始化逻辑应放在实体自身（如构造函数或 setter），而非服务构造阶段
最容易被忽略的一点：参数注入是否生效，不看代码写得有多漂亮，而要看 bin/console debug:container 'App\Service\YourService' 输出里的 Arguments 行。没出现在那里，就等于没注入成功——别猜，直接查。
