虚拟机中 composer install 卡住是因挂载卷（如 vmhgfs、osxfs）i/o 延迟高，导致数万次 stat() 和 file_put_contents() 调用阻塞；应将 vendor 和缓存移至 vm 内部磁盘（如 /tmp 或 /var/cache/composer），关闭 opcache.enable_cli 和 xdebug，并锁死依赖版本、提交 composer.lock。
为什么虚拟机里 composer install 会卡住不动
不是 Composer 慢，是它在反复读写挂载卷（比如 VMware 的 vmhgfs、WSL2 的 /mnt/c/、Docker Desktop 的 osxfs）。这些文件系统对 stat() 和 file_put_contents() 的延迟高达毫秒级，而 Composer 解析阶段要执行数万次这类调用——CPU 再强也扛不住 I/O 阻塞。
确认是否踩坑：运行 df -T .，如果输出中 Filesystem 类型是 9p、vmhgfs、osxfs 或 drvfs，就别在那个目录下跑 composer install。
vendor 和缓存必须挪到 VM 内部磁盘
把 vendor/ 和 ~/.composer/cache 移出挂载路径，是见效最快的调优动作。VM 内部磁盘（如 /tmp/composer-cache 或 /var/cache/composer）的 I/O 延迟比宿主机共享目录低一个数量级。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 改缓存路径：
composer config -g cache-dir /tmp/composer-cache - 项目级 vendor 路径可设为
"config": {"vendor-dir": "/tmp/myproject-vendor"}（写进composer.json） - 注意：
/tmp在多数 Linux VM 中是内存盘（tmpfs），速度极快但重启清空；若需持久，选 SSD 虚拟盘路径如/var/cache/composer
PHP 配置里这几个开关必须关
VM 环境下某些 PHP 配置反而拖慢 Composer 自身执行，尤其是 CPU 频率波动大时：
- 禁用 CLI 模式 opcache：
opcache.enable_cli=0（PHP 8.2+ 下opcache.enable_cli=1会让 Composer 加载变慢） - 关掉 Xdebug：
XDEBUG_MODE=off composer install或临时注释 php.ini 中zend_extension=xdebug.so - 提升内存限制：
COMPOSER_MEMORY_LIMIT=-1，避免解析依赖时因内存不足反复 GC
composer.json 里这些写法会让 VM 更卡
混合部署对依赖求解敏感，“宽泛约束”在 VM 中会放大 CPU 调度劣势：
- 删掉
"minimum-stability": "dev"—— 开发包候选集爆炸，VM 里可能卡 40 秒以上 - 避免
"^1.0 || ^2.0"或"*"这类 OR 表达式，改用锁死版本如"^2.9.0" - 禁用已废弃插件：
fxp/composer-asset-plugin，它在跨平台路径处理上有 race condition，VM 中极易重试失败 - 确保
composer.lock提交进 Git —— 没 lock 文件，每次install都要重新穷举依赖组合
真正卡住的点，往往不在网络或镜像，而在 VM 内部 I/O 和 PHP 配置的错位。哪怕换了阿里云镜像，只要 vendor 还在 /mnt/c/ 下，一样卡死。
