psr-11接口本身无性能差异，性能差异源于自动加载策略与实例化逻辑：是否启用opcache.preload、classmap-authoritative、apcu缓存，以及服务定义形式（闭包vs类名）、是否缓存已解析实例、反射调用等实现细节。
直接说结论：PSR-11 容器本身的接口（get()、has()）没有性能差异，真正影响性能的是底层自动加载 + 服务实例化策略，不是 ContainerInterface 实现本身。
为什么 PSR-11 实现之间“看起来”有性能差异
你测到的耗时差，99% 不是 get() 方法逻辑慢，而是：
- 容器是否启用了
opcache.preload预加载 —— 没预加载时，每次请求都要解析vendor/autoload.php和所有类定义 - 服务定义是闭包（
function() { return new Service(); }）还是字符串类名（'App\Service'）—— 前者每次调用都执行函数，后者可走 classmap 快路径 - 是否启用
"classmap-authoritative": true—— 若没启用，即使服务在 classmap 里，自动加载器仍会 fallback 到 PSR-4 文件扫描 - 容器是否缓存了已解析的服务实例（
$this->resolvedEntries）—— 没缓存时，get('db')调用十次就实例化十次
composer.json 中必须配对启用的三项配置
只开 "optimize-autoloader": true 是不够的，必须和另外两个配合才生效：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
"optimize-autoloader": true：触发 classmap 生成（前提是项目或依赖中配置了"classmap"或用了"files"） -
"classmap-authoritative": true：让自动加载器彻底跳过文件系统查找，只信 classmap —— 这才是提速关键 -
"apcu-autoloader": true：若 PHP 启用了 APCu 扩展，它会缓存“类名 → 文件路径”的映射，比纯 classmap 更快（但不能和classmap-authoritative同时用）
注意：composer dump-autoload -o 单独运行几乎无效，它不重建 classmap，也不读 composer.lock；生产部署必须用 composer install --no-dev --optimize-autoloader。
轻量级 PSR-11 容器实现的性能陷阱
自己写的 AbstractContainer 很容易踩坑：
- 别在
get()里做反射（new ReflectionClass()）或file_exists()—— 这些操作无法被 opcache 缓存，每次请求都重来 - 别把服务定义写成
function() { return new \Some\Class($this->get('config'));—— 闭包无法被 classmap 加速，且每次调用都重新执行 - 如果服务是单例，一定要在
get()内部做isset($this->resolvedEntries[$id])判断并复用，否则等于没容器 -
has()方法不能只查$this->definitions就返回true—— PSR-11 明确要求：若has($id)返回true，则get($id)不得抛NotFoundExceptionInterface；但反过来不成立
最常被忽略的一点：classmap-authoritative 开启后，任何运行时动态生成的类（比如 Doctrine Proxy、PHP-DI 的代理类）都会加载失败 —— 不是容器慢，是根本找不到类。这类项目必须改用 apcu-autoloader 或关掉权威模式。
