Composer install 卡在“Extracting archive”并非 APFS 缺陷，而是 ~/.composer/cache 落在低速存储或挂载方式触发 macOS 文件系统桥接层延迟，导致 ZIP 校验、元数据读取、临时文件写入三步 I/O 延迟放大。
Composer install 卡在 “Extracting archive” 是 APFS 的锅？
不是。APFS 本身不会导致 Composer 解压变慢，真正拖住的是 ~/.composer/cache/ 落在低速存储上，或挂载方式触发了 macOS 文件系统桥接层延迟。你看到的“卡住”，90% 是解压前校验 ZIP、读取元数据、写入临时文件这三步被放大了 I/O 延迟，而非 APFS 自身缺陷。
为什么挂载 vendor 目录会让 Composer 在 macOS 上崩得特别快
Docker 或 VM 中用 -v $(pwd)/vendor:/app/vendor 这种方式挂载，会强制所有 stat()、open()、read() 调用穿过 macOS 的虚拟文件系统桥接层（尤其是 FUSE/VMware Tools/Parallels Tools），在 APFS + macOS 13+ 上尤为明显。小文件密集操作（比如解压几百个 ZIP）时，单次 stat 延迟可飙到 20–50ms，累积起来直接超时。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 开发中禁用 vendor 挂载，改用命名卷：
docker run -v $(pwd):/app -v composer-vendor:/app/vendor image composer install - CI 环境确保
composer install在容器内执行，而非宿主机生成后拷贝 - 必须同步时，用
rsync -av --delete vendor/ container:/app/vendor替代实时挂载
缓存路径落在 APFS 容器里却依然慢？检查它是否被快照拖累
~/.composer/cache/ 默认在用户主目录下，而主目录是 APFS 容器的一部分。如果该容器积累了大量本地快照（如 Time Machine hourly-snapshot），即使磁盘还有空间，写入新缓存包时也会因 Copy-on-Write 分裂导致 I/O 放大——尤其当缓存里全是小文件（每个包版本一个子目录），元数据压力更大。
- 查快照数量：
tmutil listlocalsnapshots / - 清空全部本地快照（慎用）：
sudo tmutil deletelocalsnapshots / - 更稳妥做法：把缓存移出主目录容器，例如设为
/Volumes/SSD/composer-cache（需先格式化为 APFS 或 Mac OS 扩展） - 验证是否生效：
composer config -g cache-dir输出路径应指向新位置
“No space left on device” 报错但 df -h 显示空间充足？大概率是 inode 耗尽
APFS 对 inode 管理比 HFS+ 更激进，而 Composer 缓存天生制造海量小文件：~/.composer/cache/files/monolog/monolog/1.27.0/ 这类路径每个版本都建独立目录。长期不清理，df -i 显示 Use% 100%，就会在创建缓存子目录时报 failed to open stream，错误信息完全不提 inode。
- 立即检查：
df -i ~/.composer/cache - 清理旧缓存：
composer clear-cache（注意：它只清内容，不删目录结构） - 手动删掉整个缓存再重建：
rm -rf ~/.composer/cache && mkdir -p ~/.composer/cache - 预防措施：定期运行
find ~/.composer/cache -type d -empty -delete清空残留空目录
