真正拖慢php容器启动的是镜像体积大、autoloader生成慢、运行时初始化重；composer镜像源配置仅加速构建阶段的依赖下载，对容器启动无影响。
不能靠“内置 Composer 镜像配置”让微服务容器光速启动——它根本不管容器启动速度，只影响 composer install 阶段的依赖下载耗时。 真正拖慢容器启动的，是镜像体积大、PHP autoloader 生成慢、运行时初始化逻辑重，不是 Composer 源配得快不快。
为什么在 Dockerfile 里配 repo.packagist 对启动没用
全局或项目级 composer config repo.packagist 只在执行 composer install 或 composer update 时生效，而这些命令只发生在构建阶段（Docker build）。容器 docker run 启动时，Composer 已经不在内存里了，配置更不会加载。此时真正决定启动快慢的是：
- 镜像大小 → 影响
docker pull和container startup的 IO 开销 - 入口脚本是否做 heavy init（如反复扫描 vendor/autoload.php）
- PHP OPcache 是否预热、是否启用 JIT
- 是否在
ENTRYPOINT里执行composer dump-autoload --optimize这类阻塞操作
composer install 阶段提速 ≠ 容器启动提速
你在 Dockerfile 里加 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，确实能让 RUN composer install 快几秒到几十秒，但这是构建优化，不是运行时优化。容易混淆的点：
- 构建快了，不代表镜像小了；如果没清理
vendor/bin、没删 dev 依赖、没禁用 scripts，最终镜像仍臃肿 - 用了
--no-dev --no-scripts --optimize-autoloader才算真正减负；漏掉--no-scripts，某些包仍会在 install 时执行耗时 post-install-cmd -
composer.lock必须和composer.json一起COPY，否则 Docker 缓存失效，每次构建都重装
真正让微服务容器“光速启动”的三件事
启动快的本质是：最小镜像 + 最少运行时初始化 + 最快 autoload 响应。实操建议：
- 用多阶段构建：build 阶段装全量依赖并生成 optimized autoloader，final 阶段只
COPY --from=builder /app/vendor /app/vendor和可执行文件，不带composer二进制、不带.git、不带测试文件 - PHP 层面启用 OPcache 并预热：在
ENTRYPOINT前加php -d opcache.enable=1 -d opcache.preload=/app/preload.php -S 0.0.0.0:8000（preload.php 包含常用类的opcache_compile_file()） - 避免在容器启动时动态生成 autoload：不要在
ENTRYPOINT或CMD里跑composer dump-autoload；所有 autoload 应在构建阶段完成
很多人花一小时调镜像源，却忽略 vendor/ 里一个 symfony/debug 包就能让首次请求慢 800ms——启动快慢，不在源，而在你敢不敢删、会不会裁、愿不愿意预热。
