先确认 vendor 下 symlink 是否创建成功；若未建或指向错误，需检查 composer.json 中 repositories 的 path 配置是否正确、路径是否相对且无绝对路径，再删 vendor/package 后执行 composer update vendor/package --no-cache 强制重建。
本地包装不上，先看 vendor/ 下有没有 symlink
Composer 对 path 类型包的处理是创建符号链接，不是复制文件。报错说“Class not found”或“package not found”，但 composer show vendor/package 显示已安装，大概率是 symlink 没建成功或指向错误路径。
检查方式很简单：
- 运行
ls -la vendor/vendor-name/package-name，看输出是不是类似../path/to/local/package的软链；如果不是，说明没走 path 模式，而是当普通远程包去解析了 - 确认你的
composer.json中repositories字段完整且 type 是path，例如：{"type": "path", "url": "../my-local-package"} - 路径必须是相对当前项目根目录的，不能用
~/或绝对路径（Windows 下也不能用C:\）
改了本地包的 composer.json 后 autoload 不生效
Composer 安装 path 包时只读一次 composer.json 的 autoload 配置，后续你改了它，主项目不会自动感知——composer dump-autoload 也不管用，因为 autoload 规则已经固化在 vendor/composer/autoload_*.php 里了。
必须强制重建：
- 删掉
vendor/vendor-name/package-name目录（不是整个vendor/） - 运行
composer update vendor-name/package-name --no-cache - 加
--no-cache是关键：否则 Composer 可能复用旧的元数据快照，跳过重新读取本地composer.json
报错含 “cURL error 7” 或 “Connection refused” 却在装本地包
这说明 Composer 根本没走 path 流程，而是退化成查 Packagist 了——通常是因为 repositories 配置被覆盖或格式错误，导致 path 仓库被忽略。
快速验证和修复：
- 运行
composer config repo.packagist（不加-g），如果输出非空，说明项目级repositories覆盖了全局配置，且可能误删了 path 条目 - 检查
composer.json里的repositories是否为数组，且每个 item 都有type和url，缺一不可 - 别信
composer config --list的输出——它不显示被屏蔽的仓库；真实行为看composer install -vvv日志里有没有Reading /path/to/local/package/composer.json
本地包类更新了，但 PHP 还加载旧版本
常见于开发中频繁改类、加方法后仍报 Class not found 或方法不存在，其实 symlink 指向是对的，问题出在 PHP 层。
两个隐藏关卡：
- OPCache 缓存了旧的类定义：部署机或 CLI 环境启用了 OPCache，需执行
opcache_reset()或重启 PHP-FPM，仅刷新页面无效 - IDE 或 LSP 缓存了旧的 autoload 映射：VS Code 的 PHP Intelephense、PHPStorm 的索引可能没随 symlink 更新，手动触发“Reload project”或清缓存
- 确认
vendor/autoload.php文件修改时间晚于你改类的时间；如果没变，说明composer dump-autoload没触发，或你漏了--dev参数（新增了测试类或 Factory）
vendor/vendor-name/package-name 后不加 --no-cache 就跑 update。这时候 Composer 很可能从缓存里拉出旧的元数据，继续用错的 autoload 规则重建 symlink——看起来重装了，其实什么都没更新。 
