Docker容器内无需配置“Composer离线安装”，真正做法是在构建阶段将composer.phar和vendor目录预置入镜像，或通过COPY vendor、提前执行composer install --no-dev等方式实现依赖固化，确保运行时完全不依赖网络。
直接说结论：Docker 容器里不需要、也不该“配置 Composer 离线安装”——你真正要做的，是在构建镜像时把 composer.phar 和依赖包提前带进去，或让容器启动时不联网也能复用已缓存的 vendor。
为什么不能在运行中的容器里配“Composer 离线安装”
Composer 本身不是系统级服务，它只是 PHP 的依赖管理工具；所谓“离线安装”，本质是避免执行 composer install 或 composer create-project 时去访问 packagist.org。但这个动作发生在构建阶段（Dockerfile 中）或首次启动时，而不是靠容器内某个开关来“启用离线模式”。
常见错误现象：
- 容器启动后执行
composer install报错Could not resolve host: repo.packagist.org - 误以为要改
composer config --global repo.packagist ...就能离线 —— 实际上这只是换镜像源，仍需网络 - 在
docker-compose.yml里给容器加network_mode: none，结果连本地composer.phar都加载失败（权限或路径问题被掩盖）
Docker 构建阶段如何真正实现离线依赖安装
核心思路：把 vendor/ 目录或完整 composer.lock + composer.phar 一起打进镜像，不依赖运行时联网。
Docker Hub
下载
Docker Hub (hub.docker.com)。此技能适用于所有 Docker Hub 操作，包括读取、创建、更新和删除数据。只要任务涉及 Docker Hub，就使用此技能。
- 在宿主机（有网）先执行：
composer install --no-dev --optimize-autoloader，生成完整的vendor/ -
Dockerfile中用COPY vendor /app/vendor，而非RUN composer install - 如果必须用
RUN composer install（比如多环境构建），则提前把composer.phar和composer.lockCOPY 进来，并确保packagist.org不被访问：RUN php composer.phar install --no-interaction --no-plugins --no-scripts - 注意：PHP 镜像若基于
alpine，需额外装php-zip和php-xml，否则composer install会静默失败
docker-compose 启动时如何避免容器尝试联网装包
这其实是配置误用的高发区。关键点在于：不要让应用启动逻辑隐式触发 composer install。
- 检查
entrypoint.sh或启动命令，删掉类似composer install || true这种“兜底”逻辑 —— 离线环境下它只会报错并卡住 - 确认
docker-compose.yml中的volumes:没有把宿主机空vendor/目录挂载进来，覆盖掉镜像里预装好的依赖 - 如果用的是 Laravel 等框架，检查
artisan optimize或config:cache是否依赖未加载的类 —— 这类错误常被误判为“Composer 没装好”，实际是 autoloader 路径错了 - 可加一句健康检查验证：
healthcheck: test: ["CMD", "php", "-r", "echo class_exists('Composer\Autoload\ClassLoader') ? 'ok' : 'fail';"]
最容易被忽略的一点：PHP 的 opcache.enable 和 opcache.validate_timestamps 在容器里默认开启，但如果你挂载了开发用的代码目录，而没同步 vendor/，Opcache 可能缓存了旧的类路径，导致“明明 vendor 有了却提示 Class not found”。这种情况和网络无关，但排查时极易绕远路。
