因为 Composer 默认复制而非符号链接，install 不解析仓库类型，必须用 update 并配置 "type": "path"、绝对路径、"options": {"symlink": true}，且本地包 name 与 require 严格一致。
为什么 composer install 不拉你的本地修改？
因为 Composer 默认把本地包当“已发布版本”处理，哪怕你用 path 仓库类型指向本地目录，它也会缓存源码快照、跳过实时同步。你改了 src/ 里的代码，vendor/ 里根本不会变——这不是 bug，是设计使然。
实操建议：
- 确认
composer.json中的repositories配置用了"type": "path"，且路径是绝对路径（相对路径在某些系统下会失效） - 删掉
vendor/your-vendor/your-package和composer.lock中对应条目，再运行composer update your-vendor/your-package（不是install） - 加
"options": {"symlink": true}到 path 仓库配置里，让 Composer 创建符号链接而非复制文件，改源码立刻生效
怎么让 dump-autoload 真正识别你的本地类变更？
即使符号链接就位，Composer 的 autoloader 仍可能缓存旧的 classmap 或 PSR 映射，尤其当你新增或重命名了类文件时。
实操建议：
- 执行
composer dump-autoload -o会生成优化版 classmap，但会忽略未被扫描到的新文件；调试阶段改用composer dump-autoload（不带-o），强制走 PSR-4 动态解析 - 检查本地包的
autoload配置是否与实际目录结构一致，比如"psr-4": {"Vendor\Package\": "src/"}，但你把新类放到了src/Support/下却没更新命名空间，就会加载失败 - 运行
composer show -p your-vendor/your-package确认 Composer 实际加载的是 path 源，而不是 packagist 上的旧版本
如何避免 composer update 覆盖你的本地开发状态？
一旦你在项目根目录执行全量 composer update，Composer 可能按 composer.lock 里记录的 commit hash 或版本号，从远程拉取包，直接覆盖你正在调试的本地 path 包。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
实操建议：
- 永远用
composer update --with-dependencies your-vendor/your-package局部更新，避免波及其它包 - 在
composer.json的require中显式写死本地包版本为"dev-main as 999.999.999"这类虚拟版本号，防止 Composer 自动降级匹配远程 tag - 提交前记得把
repositories区块和虚拟版本号从生产环境composer.json中移除——它们不该进部署流程
调试时发现类存在但方法报 Call to undefined method 怎么办？
常见于本地包升级了接口但未更新 autoload 映射，或 IDE 缓存了旧的 stub，更隐蔽的情况是：你改了方法签名，但 PHP OPcache 没清，导致运行时仍执行旧字节码。
实操建议：
- 先运行
php -d opcache.enable=0 your-script.php排除 OPcache 干扰 - 用
composer dump-autoload --no-scripts避免 post-autoload-dump 脚本干扰，再验证基础加载 - 在目标类中临时加
die(__FILE__ . ':' . __LINE__);，确认 PHP 加载的确实是你的本地文件，而不是 vendor 里某次意外留下的副本
路径、符号链接、autoload 三者必须对齐，少一个环节，改十次代码都白搭。
