Symfony中为直接注入的服务添加readonly属性是否有用？

针对你给出的两个控制器示例，聚焦于注入的Service而非简单值类型，以下是添加readonly属性的实际场景优缺点：

优点 #

• 阻止意外篡改依赖实例：Service通常由Symfony容器管理，是单例或预定义的特定实例。如果控制器中不小心出现$this->fooService = new FooService();这类错误赋值，会破坏依赖注入的一致性，导致后续逻辑使用错误的实例。readonly能在PHP编译阶段直接拦截这类操作，避免运行时才发现问题。
• 明确代码意图，提升可读性：看到readonly修饰的Service属性，其他开发者能立刻明白这个实例从构造完成后就不会变更，无需遍历控制器所有方法去确认是否有修改操作，降低了代码维护成本。
• 契合不可变设计，减少潜在bug：让控制器的依赖状态更稳定，减少因依赖实例变更引发的难以排查的bug，在多人协作的大型项目中，这种约束能有效降低人为失误的影响。

缺点 #

• 测试时灵活性受限：在单元测试中，如果需要替换Service为Mock对象，readonly属性只能通过构造函数注入Mock，无法在测试过程中动态重新赋值。虽然构造注入是最佳实践，但在部分集成测试场景中，会增加实例替换的操作复杂度。
• 增加子类扩展的成本：如果后续需要创建控制器的子类，并重写注入的Service实例，readonly会直接阻止子类修改该属性，必须通过父类构造函数传递新实例，甚至需要重新设计依赖结构，提升了扩展的门槛。
• 极端合法场景下的阻碍：虽然Symfony常规开发中很少遇到，但如果控制器确实有动态切换Service实例的合法需求，readonly会直接阻断这种实现，不得不调整依赖注入的方式。

需要额外说明的是：与private readonly string $apiKey这类简单值类型不同，Service本身带有自身的依赖链，一旦设置readonly，若想非法修改该属性（比如通过反射），操作成本极高且难以被察觉，但这种极端情况在常规开发中几乎不会出现。

内容的提问来源于stack exchange，提问作者Martijn