改本地包代码主项目仍用旧逻辑，是因为未满足path仓库启用symlink的全部条件：repositories需显式配置"options":{"symlink":true}、url为合法相对/绝对路径、name逐字匹配、本地包已git init并commit、系统权限合规；任一缺失即静默fallback至copy模式。
能，但必须用 path 仓库 + symlink，且满足全部硬性条件；否则 Composer 会静默 fallback 到 copy 模式，改代码完全不生效。
为什么改了本地包代码，主项目里还是旧逻辑？
这不是 Composer “没刷新”，而是它压根没走 symlink 路径——默认行为就是复制（copy），只有所有前提都满足，才会建符号链接。
-
repositories里对应条目必须显式写"options": {"symlink": true}，只写"type": "path"不够 -
url必须是相对路径（如"../my-package"）或绝对路径（如/Users/me/my-package），不能带file://或~ - 本地包的
composer.json中name字段（如"acme/utils"）必须与主项目require里的包名**逐字节一致**（大小写、斜杠方向都不能错） - 本地包目录必须已执行
git init且至少有一个commit；否则 Composer 直接拒绝 symlink - Windows 下需以管理员身份运行终端，或开启“开发者模式”；macOS/Linux 需确保当前用户对本地包目录有写权限（尤其 sticky bit 或 group 权限缺失会导致 fallback）
怎么验证 symlink 是否真生效？
别信 composer update 输出，直接看 vendor/ 下的文件系统链接状态：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- macOS/Linux：
ls -la vendor/acme/utils，输出里必须含->，且指向你的本地包路径 - Windows：
dir vendor\acme\utils，应显示<symlinkd></symlinkd>类型，不是普通文件夹 - 如果看到的是完整复制出来的文件（有
src/、composer.json等），说明 symlink 失败，已 fallback 到 copy
版本约束写 "*" 为什么经常失效？
"acme/utils": "*" 会让 Composer 优先查 Packagist，可能绕过你的 path 仓库，导致根本没走本地代码。
- 推荐写法一：
"acme/utils": "dev-main"，前提是本地包composer.json中version设为"dev-main"；这样切分支后，composer update acme/utils才会重建 symlink - 推荐写法二：
"acme/utils": "@dev"，它强制走path源，不查 Packagist，也不依赖本地包的version字段，最省心 - 首次引入必须用
composer update acme/utils（不是install），因为install只读composer.lock，不重新解析仓库类型
autoload 改了为啥新类找不到？
即使 symlink 已建好，只要动了本地包的 autoload 配置（比如新增 PSR-4 命名空间、改了 src/ 映射路径），vendor/autoload.php 就不会自动识别新类。
- 必须手动刷新：在主项目根目录执行
composer dump-autoload -o -
-o（optimize）不是可选——它会生成vendor/composer/autoload_classmap.php，大幅提升类加载效率；不加也能用，但开发中容易漏掉新类 - 这个命令只影响自动加载映射，不触发依赖重安装，安全且必要
最容易被忽略的是 Git 初始化和 commit 这一步——很多开发者删掉 .git 目录图省事，结果 symlink 永远建不起来，还反复检查配置。Composer 对 symlink 的校验是“全有或全无”，少一个条件，就安静地退回到复制模式，连 warning 都不给。
