根本原因是基础镜像默认不带composer，须用官方脚本安装；挂载卷导致权限问题需指定uid/gid或构建时安装；网络问题应换国内镜像源；避免运行时执行composer install作为主命令；注意autoloader路径与workdir一致。
Composer 命令在容器里执行失败：找不到 composer 命令
根本原因是基础镜像（比如 php:8.2-cli）默认不带 Composer，得自己装。别指望 apt install composer —— 官方明确不推荐用系统包管理器装，容易版本错乱、权限异常。
- 用官方安装脚本最稳妥：
curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer
- 如果构建时网络受限，可提前下载
composer.phar并 COPY 进镜像，再设为可执行：chmod +x /usr/local/bin/composer
- Dockerfile 中别写
RUN composer install在构建阶段就跑——除非你确认vendor/不依赖宿主机环境（比如扩展、PHP 版本、扩展配置），否则大概率部署后报错
容器内运行 composer install 报 “permission denied” 或 “failed to open stream”
典型现象是挂载了宿主机代码目录（-v $(pwd):/app），然后在容器里执行 composer install，结果生成的 vendor/ 文件属主变成 root，或 PHP 进程没权限读取。
- 宿主机和容器 UID 不一致是主因。启动容器时显式指定用户：
docker run -u $(id -u):$(id -g) -v $(pwd):/app php:8.2-cli composer install
- 别让 Composer 在挂载卷里直接写
vendor/。更安全的做法是：构建阶段 COPY 代码 →composer install→ 复制vendor/到最终镜像；运行时只挂载public/或config/等需要热更新的目录 - 如果必须运行时安装（比如 CI/CD 临时调试），加
--no-scripts --no-plugins避免触发需额外权限的钩子
用 composer create-project 初始化项目时卡住或超时
容器默认 DNS 或网络策略可能限制访问 GitHub / Packagist，尤其企业内网或使用 Docker Desktop 的 macOS/Windows。
- 优先换国内镜像源，执行前先设全局配置：
composer config -g repo.packagist composer https://packagist.phpcomposer.com
（注意：该镜像已停用，实际应换为https://packagist.laravel-china.org或阿里云源） - 更可靠的是在
composer.json里硬编码仓库地址，避免依赖全局配置被忽略 - 如果用
docker build构建，记得在RUN指令里一次性完成源设置 + 安装，否则每步都走默认源，慢且不稳定
Docker Compose 启动服务时自动执行 composer install 的陷阱
很多人在 command: 里写 sh -c "composer install && php-fpm"，结果容器一启就卡死或反复重启。
-
composer install是长时任务，不是守护进程，不能当主命令跑。它执行完就退出，容器随之停止 - 真要初始化，应该用
entrypoint脚本分阶段：检查vendor/是否存在 → 不存在则composer install→ 再 exec 启动 PHP - 更常见也更轻量的做法是：把
composer install放进构建阶段，运行时镜像里已有完整vendor/，启动命令只负责起服务
最常被忽略的一点：Composer 的 autoloader 生成路径是相对当前工作目录的，而 Docker 里 WORKDIR 和挂载路径稍有偏差，就会导致 Class not found。务必确认 composer dump-autoload 执行时的 PWD 和运行时 PHP 加载文件的 PWD 一致。
