Composer install 在容器中报“no zip extension”是因为官方PHP镜像默认未启用zip和mbstring扩展，而Composer依赖它们解压包；需在Dockerfile中显式安装并启用对应扩展。
为什么 composer install 在容器里总报错 “no zip extension”
因为官方 PHP 镜像默认不带 zip 和 mbstring 扩展，而 Composer 安装依赖（尤其从 zip 包安装时）强依赖这两个。没它们，composer install 会直接失败或退化成慢速 git clone 模式。
实操建议：
- 在
Dockerfile中显式启用扩展：RUN docker-php-ext-install zip mbstring - 如果用 Alpine，改用
apk add php-zip php-mbstring，注意 Alpine 的包名不含php-前缀是常见坑 - 装完别忘重启 PHP CLI 配置（Alpine 不需要，Debian/Ubuntu 系需
docker-php-ext-enable zip mbstring）
如何让 composer install 在构建阶段不拉源码、只解包缓存
CI/CD 构建时反复下载 vendor 太慢，核心是复用 Composer 的本地缓存 + 锁定安装模式，避免动态解析依赖树。
实操建议：
- 把
composer.lock和composer.json提前 COPY 进镜像，放在vendor/之前 —— 否则 Docker 层缓存失效 - 运行命令必须加
--no-interaction --no-progress --optimize-autoloader --ignore-platform-reqs，其中--ignore-platform-reqs是为绕过容器内 PHP 版本和扩展缺失的校验（比如你还没装 ext-redis，但 lock 文件里写了） - 不要在
RUN composer create-project或require，那会触发网络请求和版本重解析，破坏确定性
composer global require 能不能放进 Dockerfile？
能，但不推荐。全局命令（如 laravel/installer、phpunit/phpunit）进容器后常因 PATH、用户权限、扩展缺失而无法执行。
实操建议：
- 改用局部安装：
composer require --dev phpunit/phpunit，再通过vendor/bin/phpunit调用，路径明确、无环境干扰 - 若真要 global，得配好
COMPOSER_HOME并确保$HOME/.composer/vendor/bin在 PATH 里，且所有依赖扩展已就位（否则 install 阶段就静默失败） - Alpine 用户特别注意：global 包的二进制可能链接了 glibc，而 musl libc 不兼容 —— 直接报
not found错误，连错误提示都看不到
Docker 构建时怎么跳过 dev 依赖又不影响 autoloader
线上镜像不该装 phpunit、faker 这类开发依赖，但漏掉它们会导致 composer dump-autoload 报错或 classmap 缺失 —— 因为某些 autoloader 规则定义在 require-dev 的包里。
实操建议：
- 用
--no-dev是对的，但必须配合--classmap-authoritative或--apcu-autoloader（如果开了 APCu），否则运行时可能找不到类 - 检查
composer.json的autoload和autoload-dev字段：如果生产代码引用了autoload-dev下的路径（比如测试工具类被误引入），--no-dev后必然报Class not found - CI 流程中建议加一步验证：
php -d display_errors=1 -d error_reporting=-1 -r "require 'vendor/autoload.php';"，提前暴露 autoloader 断链
composer install 生成的 autoload_static.php 里有硬编码时间戳，挂载宿主机 volume 时若容器时区不对，某些框架（Laravel）会拒绝加载这个文件。 
