vendor目录存在但类加载失败，大概率是autoload_static.php等文件中硬编码的绝对路径未刷新；需删除vendor/composer/autoload_*.php并运行composer dump-autoload --optimize重建。

vendor目录存在但类加载失败，大概率是路径硬编码没刷新

Composer 2.x+ 在 vendor 目录中生成的 autoload_static.php 和 autoload_files.php 会写入绝对路径（如 /home/user/project/vendor/autoload.php），一旦项目迁移到新路径（比如从 /var/www/app 拷到 /srv/app），即使 vendor 内容完全一致，PHP 也会因路径不匹配跳过自动加载逻辑，报 Class not found 或 Failed to open stream。

这不是权限或镜像问题，而是 autoload 缓存未重建：

• 删掉 vendor/composer/autoload_*.php 文件（尤其是 autoload_static.php）
• 运行 composer dump-autoload --optimize（开发环境可省略 --optimize）
• 确认 vendor/autoload.php 头部注释里写的路径与当前 pwd 一致

composer install 后 vendor 目录结构和 lock 文件不一致

常见于手动删过某个包、CI 脚本中途失败、或用 composer update 混淆了环境。此时 composer install 不会报错，但实际加载的是旧文件——因为 Composer 默认只校验包是否存在，不校验版本哈希或文件完整性。

强制全量重装并验证一致性：

• 先清空：rm -rf vendor/
• 确保 composer.lock 是最新且未被修改（git status composer.lock）
• 运行：composer install --no-dev --optimize-autoloader --no-interaction --ignore-platform-reqs（最后两个参数按需加）
• 验证：composer show --tree | head -20 对比开发环境输出

团队协作时 vendor 目录“看起来同步”但运行报错

根本原因不是 vendor 没同步，而是 composer.lock 没提交或被忽略。很多人把 vendor/ 加进 .gitignore 就以为万事大吉，却忘了 composer.lock 必须进 Git —— 它才是版本事实来源。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

检查和修复步骤：

• 运行 git ls-files | grep composer.lock，输出为空说明没提交
• 如果没提交，先 git add composer.lock，再 git commit -m "lock: pin dependencies"
• 队友拉取后，必须删掉本地 vendor/ 并重跑 composer install，不能复用旧 vendor
• CI 脚本里加前置检查：test -s composer.lock || (echo "ERROR: composer.lock missing" >&2; exit 1)

镜像配置正确但 vendor 安装仍卡在 Loading composer repositories

现象是命令挂起几秒后直接报 Could not find package，但 composer config -g repo.packagist 显示正常。这通常是因为元数据缓存仍是旧的，或者 provider-*.json 没从镜像站加载。

关键动作不是换源，而是刷新元数据索引：

• 确认镜像生效：composer update -v 2>&1 | grep "GET https" | head -3，看 URL 是否含 mirrors.aliyun.com
• 强制刷新元数据：composer update --refresh（≥2.5）或手动清理：rm -rf $(composer config --global cache-dir)/repo/https---mirrors-aliyun-com-composer
• 别依赖 composer clear-cache，它不删 provider-*.json，对元数据无效

最易被忽略的一点：vendor 目录存在时，Composer 3.x 会默认启用 classmap-authoritative，导致每次 install/update 都扫描全部文件——哪怕你只想装一个包，也要等 30 秒 I/O。关掉它：composer config authorative false（注意拼写是 authorative，不是 authoritative）。