正确做法是在项目 composer.json 中配置 type="path" 的 repositories，指定本地包相对路径，并执行 composer require vendor/name:dev-main；修改后需 dump-autoload 或 --no-cache 更新。
composer require 本地路径包报错“Could not find package”
直接 composer require vendor/name 走 Packagist 流程，当然找不到你硬盘上某个文件夹里的代码。Composer 默认只认注册过的包名，不认路径。
正确做法是先在项目根目录的 composer.json 里手动加一条 repositories 配置，告诉 Composer：“这个路径下有个包，按本地路径方式加载”。
- 确保你的本地插件目录里有合法的
composer.json（至少含name、version或autoload） -
repositories类型必须设为"path"，不是"vcs"或"package" - 路径用相对路径（相对于项目根目录），比如
../my-local-plugin；Windows 下也用正斜杠，别用反斜杠 - 执行
composer require vendor/name:dev-main（分支名要跟你本地包的composer.json里extra.branch-alias或默认分支一致）
本地插件修改后 composer update 不生效
因为 Composer 缓存了包的 dist 包或 symlink 状态，它可能以为“这包没变”，就跳过重新链接。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 改完本地插件代码后，先运行
composer dump-autoload，让 autoload 映射刷新 - 如果仍不生效，删掉
vendor/vendor/name目录，再跑composer install - 更彻底的办法：加
--no-cache参数，比如composer update vendor/name --no-cache - 确认你的本地包
composer.json中version字段没锁死（比如写成"1.0.0"），否则 Composer 会拒绝更新到未声明的版本
为什么用了 path repository 还提示 “Your requirements could not be resolved”
常见于依赖冲突——你的本地包声明了某个扩展或 PHP 版本，但当前项目环境不满足。
- 检查本地包
composer.json的require字段，特别是php、ext-curl这类硬依赖 - 运行
composer why-not vendor/name:dev-main查看具体哪条约束被卡住 - 如果只是开发调试，可临时在本地包中放宽
require.php（比如从"^8.1"改成=7.4.0 ），但上线前得还原 - 注意：
path类型仓库不会自动校验require-dev，但如果你在主项目里启用了--with-all-dependencies，它就会参与解析
本地插件如何支持热重载（改代码不重启 CLI/HTTP 服务）
Composer 的 autoloader 本身不监听文件变化，所谓“热重载”靠的是自动重生成映射 + 应用层配合。
- 确保本地插件用的是
"psr-4"或"classmap"自动加载，别用"files"手动引入（后者不会随文件变更自动重载） - 开发时加个 watch 脚本：用
composer dump-autoload --optimize配合inotifywait或watchexec，检测到src/变化就触发重生成 - PHP-FPM 或 Swoole 场景下，autoloader 缓存由 OPCache 控制，需关掉
opcache.enable_cli（CLI）或清 OPCache（Web） - 别指望
composer install自己监听文件——它从来就不是热重载工具
路径映射这事看着简单，但 name 冲突、分支别名缺失、OPCache 滞后、autoload 缓存残留……任何一个环节卡住，都会让你以为“路径配置没生效”，其实只是 Composer 在安静地坚持自己的规则。
