私有服务应优先通过构造函数注入而非容器获取；测试中可用static::$container->get()配合类名获取；开发调试可局部覆盖services_dev.yaml设public: true。
私有服务不能直接用 $container->get('service_id') 获取，但你完全不需要把它改成 public: true ——那会破坏容器契约，而且只在测试或调试时临时放开，也容易误提交到生产环境。
测试中直接用 static::$container->get() 拿私有服务
Symfony 4.1+ 的 KernelTestCase 和 WebTestCase 已内置一个“宽松容器”，它允许按类名获取私有服务，且仅限测试生命周期内生效：
- 必须先调用
self::bootKernel()，否则static::$container是 null - 只能用类名（如
MyService::class）或已配置的别名，不能用字符串 ID（如'app.my_service'） - 该容器不加载 prod 配置，不受
services.yaml中public: false限制 - 无需改任何服务定义，零配置成本
开发环境局部公开单个服务（仅限本地）
如果要在 bin/console 或 php -S 下临时调试某个服务，可在 config/services_dev.yaml 中覆盖定义：
- 确保该文件只被
dev环境加载（检查config/packages/dev/是否包含它） - 写法是：
App\Service\MyService: public: true，不是整个services:块重写 - 切勿在
services.yaml或prod相关配置里加public: true - Git 忽略该文件或加 commit hook 提醒，避免误入版本库
构造函数注入比手动 get() 更安全
当你真正需要使用私有服务时，90% 的场景应该靠类型提示自动注入，而不是手动从容器取：
- 保持服务私有（默认即可），在目标类构造函数中声明
function __construct(MyService $service) - 容器会自动匹配并注入，连服务 ID 都不用记
- 避免硬编码依赖、规避
get()调用带来的作用域污染和测试耦合 - 如果服务本身依赖复杂（比如要传参数），就在
services.yaml里配好arguments，注入时完全透明
最容易被忽略的是：私有服务在非测试容器里根本无法用字符串 ID 获取，哪怕你写了 public: true 也得确认它没被其他配置覆盖；而构造函数注入看似多写一行 type hint，实际省掉所有生命周期管理、mock 替换和可见性判断的麻烦。
