应使用path仓库类型配置本地目录，因其稳定可复现；在主项目composer.json中添加repositories块（url为相对路径），本地包需含合法composer.json，require写为"*"或"dev-main"，再运行composer update vendor/name，成功后vendor内即为指向本地的符号链接。
直接用 path 仓库类型配本地目录，别碰 composer link —— 它只对已安装包生效、不改 composer.lock、后续 composer update 极易覆盖掉软链接。
为什么 composer install 总是拉远程包，不认你改的本地代码？
因为 composer.lock 锁死了哈希和版本号，install 只照单执行，完全无视 vendor/ 下你手改的任何内容。这不是 bug，是设计：保障部署可重现。但调试时你需要的是“绕过锁定，直连源码”。
-
composer dump-autoload不解决来源问题，它只刷新自动加载映射 - 手动改
composer.json里的"version"字段无效，Composer 会忽略 - 依赖写成
"dev-main"或"*@dev"也不行——没配仓库类型，它还是去 Packagist 找
怎么用 path 仓库让 vendor 变成符号链接？
这是最稳、可复现、适合团队协作的方式。关键就三步：
- 在主项目
composer.json顶部加repositories块，url必须是相对路径（如"../my-package"），不能用~/或绝对路径 - 确保本地包目录下有合法的
composer.json（至少含name和version或minimum-stability） - 把主项目的
require改成通配版本，比如"acme/my-package": "*"—— 这会让 Composer 自动匹配本地包的version或推断为dev-main - 运行
composer update acme/my-package（必须带包名，否则可能误更新其他依赖）
成功后，vendor/acme/my-package 就是符号链接，指向你本地目录。改代码，立刻生效。
Windows 上 symlink 失败怎么办？
报错 failed to create symbolic link 是常见现象，不是配置错，是系统权限限制：
- 以管理员身份运行终端（CMD/PowerShell）
- 或启用 Windows 开发者模式（设置 → 更新与安全 → 针对开发人员 → 开发者模式）
- 某些 CI 环境或旧版 Composer（--no-interaction --prefer-source 强制
如果误删 vendor 或重装依赖，symlink 会消失——这不是 bug，是预期行为；重新跑一遍 composer update 即可恢复。
真正容易被忽略的点是：本地包的 composer.json 里若没声明 autoload 规则（尤其是 PSR-4 映射），即使 symlink 成功，类也加载不了。别只盯着路径， autoload 配置必须同步有效。
