create-project卡在“Extracting archive”是因低速磁盘导致小文件I/O延迟飙升，而非网络问题；应迁移cache-dir至SSD或tmpfs、禁用vendor挂载、清理缓存并关闭Xdebug等冗余功能。
为什么 create-project 在低速磁盘上卡在 “Extracting archive”
不是网络慢，是 Composer 解压几百个 ZIP 包时反复调用 stat()、open()、read()，而机械硬盘或挂载卷（尤其是 macOS/Windows 上的 Docker -v）会让这些小文件 I/O 延迟飙升。你看到的 “Extracting archive” 卡 40 秒以上，No space left on device 报错但 df -h 显示空间充足，基本就是 inode 耗尽或底层存储响应太慢。
- 禁用 vendor 目录实时挂载：Docker 中别用
-v $(pwd)/vendor:/app/vendor，改用命名卷-v composer-vendor:/app/vendor - 把 Composer 缓存移出低速盘：运行
composer config -g cache-dir /mnt/ssd/composer-cache（确保路径可写、不在 NFS 或 overlay2 上） - 临时用内存盘（Linux）：
sudo mount -t tmpfs -o size=2G tmpfs /mnt/ramdisk，再设cache-dir指向它 - 清理旧缓存避免损坏包干扰：
composer clear-cache，尤其之前失败过
如何绕过解压阶段直接复制 vendor 内容
create-project 默认走 dist 包（ZIP），但解压仍是瓶颈。真正快的方式是跳过下载+解压，让 Composer 直接从缓存硬链接或复制——这要求你已成功执行过一次，且缓存完整。
- 加
--prefer-dist强制走压缩包（默认已启用，但显式写明更稳妥） - 加
--no-scripts防止 post-autoload-dump 等脚本触发额外文件操作 - 加
--no-autoloader避免生成 autoload 文件时扫描整个vendor - 确保
COMPOSER_CACHE_DIR指向 SSD 或 tmpfs，否则硬链接也慢
为什么 --no-dev 还是慢？检查依赖树是否真被裁剪
--no-dev 只跳过 require-dev 里声明的包，但若这些包又被主依赖间接引入（比如 phpunit 被某个 dev-require 的工具链依赖），它们仍会被拉下来。I/O 压力没减少。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 先跑一次
composer show --tree，确认 dev-only 包是否真没出现在依赖树里 - 删掉
composer.lock后再试create-project，避免锁文件残留 dev 分支引用 - 用
composer why phpunit（举例）查清谁拖进了 dev 包，针对性排除 - 生产环境初始化建议加
--stability=stable，避免自动选dev-main触发源码克隆
磁盘 IO 瓶颈下最该关掉的三个东西
有些功能默认开启，但在低速盘上会反复读写小文件，放大延迟。关掉它们比换镜像更立竿见影。
- 关 Xdebug：
php -d zend_extension= -d xdebug.mode=off /usr/bin/composer create-project ...，解析阶段慢 5–10 倍 - 关自动加载优化扫描：
--no-autoloader+ 后续手动composer dump-autoload --classmap-authoritative（等 vendor 就位后再做） - 关 Git 元数据：
--remove-vcs，避免git clone后反复git rev-parse查 commit hash
实际执行时，create-project 的 I/O 压力主要集中在缓存目录和目标目录的写入节奏上。哪怕镜像再快、并发再高，如果 cache-dir 还在机械硬盘上，或者目标目录所在文件系统不支持高效小文件写入，提速就只是假象。
