symlink 模式未生效是因为 composer 默认禁用符号链接，仅当显式配置 "options": {"symlink": true} 且满足权限、路径、命令阶段（必须用 update 而非 install）等全部前提时才创建；否则静默降级为硬拷贝。
symlink 模式为什么没生效，却看到 vendor 里是完整副本？
不是配置漏了，就是条件没凑齐——Composer 默认不 symlink，只在显式启用且所有前提满足时才尝试创建。常见失效场景包括：
• composer install 执行了，但 symlink 只在 composer update 阶段触发，install 完全按 composer.lock 还原，连仓库类型都不重新判断
• Windows 下终端未启用「开发者模式」或未以当前用户身份运行（不是管理员 CMD），mklink 被系统拒绝，Composer 静默 fallback 到 copy
• "options": {"symlink": true} 放错了位置：必须写在主项目 composer.json 的 repositories 条目里，或本地包自己的 composer.json 根级（不是主项目的顶层）
• 路径不合法：含 ~、$HOME、单反斜杠 \（Windows）、或目标目录不存在
path 仓库中 symlink 和 copy 的实际行为差异
二者根本不是“开关切换”，而是不同阶段的产物：
• symlink 是 composer update 时由 Composer 主动调用系统接口（symlink() 或 mklink）创建的符号链接，指向本地源码目录
• copy 是 fallback 行为：当 symlink 创建失败（权限/路径/配置任一不满足），Composer 自动降级为硬拷贝，内容与源码一致但无联动
• 二者共存于同一项目不可能：一次 update 后，vendor/vendor/name 要么是 -> 链接，要么是普通目录，不会混合
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
什么时候该选 symlink，什么时候必须用 copy？
选型取决于开发流程和环境约束，不是偏好问题：
• 选 symlink：本地多包协同开发（如 monorepo）、需实时调试、磁盘空间敏感、PHP opcode 缓存可控（可配合 composer dump-autoload 更新映射）
• 选 copy：CI/CD 构建环境（无 symlink 权限）、Windows 普通用户无法启用开发者模式、部署到只读文件系统、或需要确保依赖完全隔离不随源码变动
• 注意："options": {"symlink": false} 可强制禁用 symlink，但 "symlink": "true"（字符串）无效，必须是布尔值 true
验证 symlink 是否真生效的三步检查法
别只看代码改了没效果，先确认链接本身是否成立：
• 运行 ls -la vendor/vendor-name/package-name（macOS/Linux）或 dir vendor\vendor-name\package-name（Windows），输出中必须含 -> 字符才表示是 symlink
• 查看 composer.lock，搜索该包名，确认 "source": {"type": "path"}，而非 "type": "git" 或缺失 source 字段
• 修改本地包中一个类的返回值，然后在主项目中调用它——如果结果立即变化，说明 symlink 生效；否则检查 PHP OPcache 是否缓存了旧的 autoloader 映射
