直接挂载vendor目录会加剧macOS/Windows性能问题并导致Class not found错误，因其触发gRPC-FUSE/VirtioFS跨虚拟机频繁小文件访问，应改用子路径挂载或容器内安装。
直接挂载 vendor 目录到容器里，不是优化，是自找麻烦——它既不能真正规避 IO 磨损，反而会放大 macOS/Windows 下的性能问题，还可能让容器启动就报 Class not found。
为什么 vendor 挂载反而加剧磁盘 IO 压力
根本原因不在 Docker 本身，而在宿主机文件系统层：Docker Desktop 在 macOS 上用 gRPC-FUSE，在 Windows 上用 VirtioFS 或 Hyper-V 共享机制，对大量小文件（vendor/ 通常含数千个 PHP 类文件）的随机读取效率极低。每次 require 都触发一次跨虚拟机边界的文件访问，I/O 延迟陡增，SSD 寿命消耗反而更集中。
- 这不是配置能调优的问题，是架构限制；改
docker-compose.yml的cached或delegated标志基本无效 - 挂载空目录或未初始化的
./vendor会导致容器内vendor/被覆盖为空，autoload.php找不到，直接崩 - 即使宿主机
vendor存在，文件时间戳、权限、符号链接在挂载后常不一致，Composer 自动加载器可能跳过部分类
真正降低 IO 磨损的挂载策略
核心思路是：避开挂载 vendor，只挂载开发必需的、变更频繁的源码路径，并把依赖固化进镜像。
- 用子路径挂载，例如
./src:/var/www/html/src:ro，./config:/var/www/html/config:ro，完全不碰vendor/ - 开发时如需更新依赖，走
docker-compose run --rm --no-deps php composer update，在干净容器中生成新vendor并写回镜像层，而非宿主机目录 - 若必须保留本地
vendor（如 legacy 项目调试），先确保它存在且非空：mkdir -p vendor && touch vendor/.keep，再挂载，避免覆盖 - 对 Composer 缓存目录挂载要克制：只挂
${COMPOSER_CACHE_DIR:-$HOME/.composer/cache}，不挂整个~/.composer，减少 UID/GID 权限冲突导致的反复下载
read_only 挂载对 SSD 寿命的实际影响
:ro 不减少写入量，只阻止容器内进程发起写操作；真正的磨损来自宿主机文件系统本身的日志、元数据更新和 TRIM 未启用。但 :ro 能防止应用误写配置或日志到挂载点，间接减少意外 I/O。
- 静态资源、配置文件、证书等明确只读内容，务必加
:ro，比如./nginx.conf:/etc/nginx/nginx.conf:ro - 不要给
/app整体加:ro，否则 Laravel 的storage/logs、Symfony 的var/cache会写失败 - 命名卷（如
app_cache:/var/www/html/var/cache）比绑定挂载更适合运行时可写数据，它走 Docker 存储驱动，IO 更可控
最常被忽略的一点：所谓“规避磁盘磨损”，本质是减少不必要的、高频的小文件随机写。挂载 vendor 却又不让它参与构建流程，等于把本该一次性完成的 IO 拆成成千上万次——这比老老实实多阶段构建并复制 vendor 到镜像里，更伤 SSD。
