彻底解决配置Composer path仓库导致的缓存滞后问题-composer-PHP中文网

path仓库require成功但代码没更新，90%是symlink没生效：需在本地包composer.json中声明"options": {"symlink": true}，验证用ls -la vendor/vendor/name看→符号；windows须管理员权限，docker需--cap-add=sys_admin；name字段大小写及vendor名必须与require完全一致；autoload未更新需执行composer dump-autoload -o；metadata缓存顽固，应手动清理~/.composer/cache/repo/https---*。

彻底解决配置composer path仓库导致的缓存滞后问题

path仓库require成功但代码没更新，90%是symlink没生效

本地包改了代码，composer install却没同步进vendor/——这不是缓存问题，是Composer fallback到了copy模式。它只在本地包自己的composer.json里声明"options": {"symlink": true}时才真正创建符号链接。

验证方式很简单：ls -la vendor/vendor/name（Linux/macOS）或dir vendor\vendor\name（Windows）。看到箭头（→）或JUNCTION才是symlink；纯文件夹就是copy，改本地源码毫无意义。

Windows用户必须以管理员身份运行终端，否则symlink创建静默失败
Docker容器需加--cap-add=SYS_ADMIN且挂载方式支持symlink（如bind而非cached）
路径末尾不能带/，"url": "../my-pkg/"会被整个仓库忽略
本地包composer.json中name字段必须和主项目require里写的完全一致：大小写、短横线-、vendor名，一个字符都不能差

删了vendor重装还是旧代码？检查autoload映射是否包含真实路径

symlink建对了，new MyClass()仍报类不存在——说明autoload没加载到本地包的真实路径。Composer不会自动把path仓库的psr-4或classmap映射注入主项目的自动加载器。

必须手动触发重建：composer dump-autoload -o。这个命令会扫描所有已启用仓库（包括path类型），把本地包的autoload段合并进vendor/composer/autoload_classmap.php和autoload_psr4.php。

别依赖IDE自动刷新——Xdebug断点失效常因IDE配置的路径和磁盘真实路径不一致（比如Docker里挂载为/var/www/my-pkg，IDE却指向./my-pkg）
如果本地包用了files autoload，也要确保主项目composer.json里没禁用autoload.files继承
composer dump-autoload后检查vendor/composer/autoload_static.php里是否出现了你的本地命名空间

为什么composer update拉不到新tag？metadata缓存比文件缓存更顽固

你刚在本地包里打了v1.2.0 tag，composer update却还停在v1.1.0——不是网络或镜像问题，是Composer缓存了旧的packages.json元数据，根本没去读Git仓库最新状态。

Discussion Composer

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

下载

path仓库的metadata缓存藏在~/.composer/cache/repo/https---github.com-xxx/这类目录下（即使你用的是本地路径，Composer也会按Git URL生成缓存子目录），composer clear-cache默认不碰它。

最准的清理方式：rm -rf ~/.composer/cache/repo/https---*（注意三个短横线）
补一刀：rm -f vendor/composer/installed.json composer.lock，强制重新解析依赖树
验证是否重拉元数据：加-v参数跑composer update -v，看到Downloading https://.../packages.json才算真正刷新
如果本地包是Git仓库，确保git fetch --tags已执行，否则Composer连本地tag都看不到

CI里path仓库总失败？环境变量和权限比配置更关键

本地好好的path仓库，一上CI就Could not find package——大概率是COMPOSER_CACHE_DIR被覆盖，或~/.composer目录权限不对，导致Composer静默fallback到默认路径，而那个路径下根本没有你的path仓库定义。

CI里唯一可靠的做法是显式设环境变量并验证：COMPOSER_CACHE_DIR=/tmp/composer-cache，然后立刻mkdir -p $COMPOSER_CACHE_DIR并chown -R $USER:$USER $COMPOSER_CACHE_DIR。

别信composer config --global输出——composer diag里的Cache directory:才是真实生效路径
GitHub Actions中，actions/cache@v4的path必须精确到~/.composer/cache，不能只缓存vendor/或~/.composer
GitLab CI里若用cache:paths，写- ~/.composer-cache-8.2这种自定义路径，要同步改COMPOSER_CACHE_DIR，否则缓存键和实际路径错位
所有CI步骤里避免用export COMPOSER_CACHE_DIR=，它只对当前shell有效；统一在job级env:里声明

路径、symlink、autoload、metadata、CI环境变量——这五处任何一个环节出偏差，都会让path仓库表现得像“缓存滞后”，其实根本没走缓存。