答案是：version字段必须写在本地包自己的composer.json中，且仅接受合法语义化版本（如"1.2.3"），主项目require中只能用"*"，其他版本约束无效；name必须与require逐字一致；repositories配置需严格满足type为"path"、url指向含composer.json的目录等条件。
path依赖的version字段必须写在本地包自己的composer.json里
主项目composer.json中require写"myorg/mylib": "*"，不代表你能随便填version；真正起作用的version值，必须出现在**本地包目录下的composer.json**中，且格式必须是合法语义化版本（如"1.2.3"），不能是"1.2"、"v1.2.3"或"dev-main"。
常见错误是主项目改了require却忘了进本地包目录改它的composer.json——结果composer install装出来的还是旧版，因为Composer读的是本地包文件里的version，不是你“以为”的那个。
- 本地包
composer.json必须有name字段，且与主项目require中的字符串完全一致（大小写、短横线、vendor名） -
version字段只接受X.Y.Z格式，不支持占位符（如@package_version@）、Git 插值或构建脚本变量 - 如果本地包没
version字段，Composer会 fallback 到dev-main，此时"*"实际指向的是当前目录 HEAD，不是你想要的稳定快照
主项目require里只能用"*"，其他版本约束全部无效
你在主项目composer.json的require里写"myorg/mylib": "^1.2.0"或"1.2.3"，Composer会静默忽略这些符号，仍按本地包composer.json里的version安装，并可能报Skipped tag v1.2.0, no composer.json found警告（尤其当你本地没打 Git tag 时）。
原因很直接：path仓库不参与语义化版本解析，它本质是“挂载”而非“拉取”。所有^、~、=、@stable都无意义，写了反而误导人。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 唯一推荐写法：
"myorg/mylib": "*" - 别写
"myorg/mylib": "dev-main"——path类型不识别分支名 - 别写
"myorg/mylib": "1.2.3@stable"——@后缀只对dist/source有效，对path无效 - 想“锁定内容”，靠的是文件系统状态（比如Git commit hash）或手动更新本地包的
version并提交，不是靠主项目写死版本字符串
repositories配置错一个字符，path依赖就彻底消失
path依赖90%失败不是因为版本号，而是repositories配置不合法：url路径不对、type写错、name不匹配，都会导致composer show --all里压根看不到你的包名。
关键检查点：
-
type必须是"path"，不是"package"或"vcs" -
url必须指向**含composer.json的目录**，且是相对于主项目composer.json的路径（如"./packages/mylib"），末尾不能加/ - Windows下路径含空格或中文会导致解析失败；Docker需
--cap-add=SYS_ADMIN才可能启用symlink - 确认本地包
composer.json语法合法（无尾逗号、全双引号、JSON有效）
改了本地代码没生效？大概率symlink没真正启用
path依赖默认尝试创建符号链接，但失败时会静默fallback到copy模式——你改本地源码，vendor/里仍是旧副本，调试半天才发现根本没联动。
真正启用symlink的关键不在主项目，而在**本地包自己的composer.json**：
- 必须有
"options": {"symlink": true}字段 - Windows需管理员权限运行终端；Linux/macOS可用
ls -la vendor/myorg/mylib确认是否为箭头链接 - Docker容器挂载宿主机目录时，常因
sys_admin缺失或挂载方式（如:ro）导致symlink失败 - autoload不更新？执行
composer dump-autoload -o手动刷新映射，别等自动触发
"*"就只是个幻觉。
