不能直接挂载宿主机 vendor 目录，因其会覆盖镜像预装依赖，并引发 PHP 版本/扩展不兼容、UID/GID 权限冲突及 macOS/Windows 文件系统性能瓶颈三重问题；正确做法是仅挂载 Composer 缓存目录并显式对齐 UID，源码则通过 ro 子目录挂载，禁用 opcache 保障热更新。
不能直接挂载宿主机的 vendor 目录进容器做联调——这不是配置问题，是根本不可行的设计冲突。
为什么 vendor 挂载必然失败
挂载 ./vendor 到容器内（如 -v ./vendor:/var/www/html/vendor）会覆盖镜像里预装的依赖，且带来三重不兼容：
- PHP 运行时版本或扩展差异，导致
vendor/composer/autoload_*.php生成逻辑失效，运行时报Class not found - 宿主机文件 UID/GID 与容器内用户（如
www-data）不一致，autoload 文件无法被读取或写入 - macOS/Windows 下 Docker Desktop 的文件系统层对
vendor中数千个小文件的读取极慢，composer dump-autoload耗时翻倍
本地联调时该挂载什么
真正可安全挂载、能加速开发流程的是 Composer 缓存目录，不是 vendor。它不绑定 PHP 环境，只存下载归档和 Git 克隆副本：
- 只挂载子目录：
${COMPOSER_CACHE_DIR:-$HOME/.composer/cache}:/root/.composer/cache:delegated - 必须对齐 UID：在
docker-compose.yml中显式指定user: "1001:1001"（用id -u查宿主机 UID） - Alpine 镜像需额外确保
/root/.composer/cache可写，或改用--user www-data并chown -R www-data /root/.composer
如何让本地修改实时生效（又不碰 vendor）
联调核心诉求是代码改了立刻生效，不是“复用宿主机 vendor”。正确路径是：
立即学习“PHP免费学习笔记（深入）”；
- 挂载源码子目录，例如
./src:/var/www/html/src:ro，避开vendor和composer.json - 容器内执行
composer dump-autoload --optimize（仅重生成 autoload 映射，不下载包） - 若需新增类或改命名空间，先在容器内跑
composer require xxx，再提交更新后的composer.lock - 开发阶段禁用 opcache：
opcache.enable=0，避免缓存旧类定义
Mac/Windows 下唯一有效的性能补救
不是调参数，而是绕开文件系统瓶颈：
- 绝对不要挂载
./vendor；如果项目结构强制要求整目录挂载，至少加:cached后缀：./src:/var/www/html:cached - CI 或构建阶段用多阶段 Dockerfile 预装
vendor，运行时镜像只含代码 + vendor，不挂载 - 本地联调时，把 composer 命令封装进
docker-compose run --rm app composer ...，确保环境一致性
真正麻烦的从来不是怎么挂，而是挂什么——vendor 是构建产物，不是共享资源；它的归属权、权限、生成环境都绑定在容器内。强行跨环境挂载，等于拿一把钥匙去开三把锁，每把都错位。
