PHP 8.5 不提供原生服务容器或 PSR-11 实现，所谓“PHP 8.5 服务容器”实为第三方库（如 php-di、Symfony DI）在该版本环境下的运行；需注意兼容性问题与反射等新行为变化。
PHP 8.5 没有原生服务容器
PHP 8.5 本身不提供服务容器，也不内置 PSR-11 实现。所谓“PHP 8.5 服务容器”，其实是你在用某个第三方库（比如 php-di、symfony/dependency-injection 或 laravel/framework）时，运行在 PHP 8.5 环境下——PHP 版本只是执行环境，不是容器来源。
如果你刚升级到 PHP 8.5 并发现容器报错，大概率是依赖库还没适配 8.5 的新行为（比如更严格的类型检查、废弃的反射 API），而不是 PHP “突然支持容器”了。
PSR-11 容器接口必须手动实现或选用兼容库
PSR-11 是个契约（ Psr\Container\ContainerInterface ），只定义了 get() 和 has() 两个方法。它不负责实例化、作用域管理或自动注入——这些全靠你选的实现来处理。
直接手写一个最小可用的 PSR-11 容器非常简单，但生产环境不推荐：
PHP 8.5.12
下载
修复 Core bailout 状态损坏安全问题，以及 BZ2、DOM、PDO、Opcache/JIT 内存与执行错误，改进 Unicode 字素处理、URL 解析、TLS 流状态、信号分发及会话错误处理。
立即学习“PHP免费学习笔记（深入）”；
class SimpleContainer implements \Psr\Container\ContainerInterface
{
private array $services = [];
public function set(string $id, callable $factory): void
{
$this->services[$id] = $factory;
}
public function get($id)
{
if (!isset($this->services[$id])) {
throw new \Psr\Container\NotFoundExceptionInterface();
}
return $this->services[$id]($this);
}
public function has($id): bool
{
return isset($this->services[$id]);
}
}
- 这个类满足 PSR-11，但没解决循环依赖、单例生命周期、参数绑定等实际问题
- PHP 8.5 下要注意：如果用了
ReflectionParameter::getType()做自动注入，某些旧版容器库可能因返回ReflectionNamedType或ReflectionUnionType处理不当而崩溃 -
php-di7.0+、symfony/dependency-injection6.4+ 已声明支持 PHP 8.5，但需确认你装的是最新小版本（比如php-di/php-di:7.0.5而非7.0.0）
PHP 8.5 下容易踩的容器相关坑
不是所有“能跑”的容器代码，在 PHP 8.5 上都真正安全。几个高频翻车点：
- 用
func_get_args()+call_user_func_array()做参数透传的容器封装，在 PHP 8.5 中可能因严格类型推导失败而抛TypeError - 某些老库通过
is_callable()判断服务是否可构造，但在 PHP 8.5 中对静态方法闭包返回false（已知 bug，PHP 8.5.0 修复，但部分中间层缓存了判断结果） - 配置文件里写了
__invoke作为工厂，但类没实现该方法——PHP 8.5 的错误提示更早、更硬，不会默默 fallback - 使用
new $className(...$args)时若$className是带命名空间的字符串，PHP 8.5 对反斜杠转义更敏感，路径拼错会直接Fatal error: Uncaught Error: Class "Foo\Bar" not found
怎么验证你的容器真支持 PHP 8.5
别只看 composer require 兼容字段，得实测关键路径：
- 启动时是否报
Deprecated: Function ReflectionType::__toString() is deprecated？这是用了过时反射写法的信号 - 尝试注册一个带联合类型参数的类（如
function foo(string|int $x)），看容器能否正确解析并注入 - 用
var_dump($container instanceof \Psr\Container\ContainerInterface)确认接口实现没被自动代理层破坏 - 如果用了 AOP 或代理（比如
goaop），PHP 8.5 的 opcache JIT 可能导致代理对象无法被get()正确识别为服务实例
最省事的方式：删掉 vendor，用 composer require php-di/php-di:^7.0（确保锁在 7.0.5+），然后跑一遍你项目里所有 service 的 get() 调用。只要没 TypeError、没 Deprecated、没找不到类，基本就稳了。
