结论：Docker中Composer应优先在构建阶段执行composer install，而非运行时；需用--no-dev和--optimize-autoloader、确保文件位置与权限正确、配置国内镜像源、避免容器内update，并设置COMPOSER_HOME指向可写路径。
直接说结论：在 Docker 容器里用 Composer，不是“装上就能跑”，而是得看你是构建镜像时用，还是进容器后临时用——两者路径、权限、缓存、网络策略全都不一样。
构建阶段用 composer install（推荐做法）
绝大多数 PHP 应用部署时，依赖应该在 Dockerfile 构建镜像时就装好，而不是运行容器时再拉包。这样镜像可复现、启动快、不依赖外部网络。
- 必须用
--no-dev和--optimize-autoloader（生产环境不装开发依赖、生成高效自动加载） - 确保
composer.json和composer.lock在构建上下文里，且放在COPY命令靠前位置，利用 Docker 层缓存 - 别在
root用户下运行composer install；如果基础镜像用非 root 用户（如www-data），提前USER切换并确保该用户对/var/www有写权限 - 常见错误：
Could not open input file: composer.phar—— 说明没把composer命令装进镜像，要么用官方composer镜像做多阶段构建，要么在 PHP 镜像里加curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer
运行中执行 composer require（慎用）
容器运行时手动装包，只适合调试、本地开发或 CI 临时验证，绝不能出现在生产镜像或 k8s Pod 启动逻辑里。
- 容器默认是无状态的，
composer require写入的vendor/和修改的composer.json在容器重启后就丢 - 如果非要试，先确认容器内 PHP 版本和扩展满足包要求（比如
ext-gd、ext-xml），否则会卡在Package manifest could not be loaded - 挂载宿主机目录时注意权限：Mac/Windows 上挂载的文件默认 uid=0，但容器内 PHP 用户可能是 uid=1001，导致
composer写缓存失败，报错Failed to write cache file - 国内环境记得设镜像源：
composer config -g repo.packagist composer https://packagist.phpcomposer.com（注意该源已停，应改用https://packagist.proxy.huaweicloud.com或阿里云源）
composer update 在容器里基本等于自找麻烦
它会改 composer.lock，而这个文件通常受 Git 管控。容器里改了也提交不了，下次构建又回退 —— 纯属扰乱协作流程。
- 真正需要升级依赖时，应该在宿主机上跑
composer update，提交新的composer.lock，再重建镜像 - 如果非要在容器里跑（比如 CI 测试兼容性），务必加
--dry-run先看变更，且禁止写入宿主机挂载的 lock 文件（避免误提交） - 注意 PHP 版本差异：宿主机 PHP 8.2 跑
update，但容器里是 8.1，可能导致锁文件记录了不兼容的版本，构建时报Your requirements could not be resolved
最常被忽略的一点：Composer 的全局配置（COMPOSER_HOME）在容器里默认指向 /root/.composer，但如果你用非 root 用户，它会 fallback 到 $HOME/.composer —— 而很多轻量镜像压根没设 $HOME，结果缓存全失效，每次重下包。解决方法很简单，在 Dockerfile 里加一行：ENV COMPOSER_HOME=/tmp/composer，再确保该路径可写。
