错，Composer path依赖默认是硬复制；仅当项目composer.json的config中设"symlink": true时才启用软链接，且需删除vendor目录后运行composer update并用ls -la验证->符号。
Composer path 依赖默认就是软链接？错，其实是硬复制
Composer 的 type: "path" 仓库默认行为是**硬复制（copy）**，不是软链接。只有当项目根目录的 composer.json 中明确设置了 "symlink": true，才会对所有 path 类型依赖启用符号链接。换句话说：你不需要“限制只能生成软链接”，而是得先确认它是不是被意外关掉了。
常见错误现象：
- 本地包改了代码，主项目却没生效 → 实际是 vendor 下仍是 copy，没连到源码
-
ls -la vendor/vendor/name看不到->符号 → 说明根本没走 symlink - Windows 上执行
composer update没报错，但 vendor 里还是文件夹 → 很可能 fallback 到 copy 且静默了
如何确保 path 依赖一定走软链接
关键不是“限制”，而是“显式开启 + 验证生效位置”。symlink 是全局开关，不支持 per-package 控制。
- 在项目根目录
composer.json的config段写："symlink": true（注意不是"symlinks"或其他拼写） - 删掉
vendor/vendor/name目录（已有 copy 不会自动转 symlink） - 运行
composer update vendor/name（必须带包名，否则可能跳过） - 用
ls -la vendor/vendor/name确认输出含-> ../my-local-package - Windows 用户需以管理员身份运行终端，或提前测试
mklink /D test .是否成功
为什么加了 "symlink": true 还没生效
原因往往不在配置本身，而在作用域和残留状态。
-
composer config --global symlink true会影响所有项目，但优先级低于项目级配置；如果项目composer.json里写了"symlink": false，它就赢了 - 已存在的 vendor 目录不会被覆盖：即使你开了
symlink，composer update也不会把现有 copy 改成 link，必须手动删掉再重装 -
repositories块里 url 必须是相对路径（如"../my-pkg"），不能是~/my-pkg或绝对路径，否则 Composer 直接忽略 symlink 逻辑 - 目标目录下若无合法
composer.json（比如缺name字段），Composer 会退回到 dist 安装模式，完全绕过 path + symlink 流程
symlink 开关只对 path 有效，别指望它管 Git 或 dist 包
这是最容易被忽略的边界：无论你把 "symlink": true 设得多坚决，它只影响 type: "path" 的仓库。对以下情况完全无效：
-
git@github.com:vendor/name.git这类 VCS 仓库 → 始终 clone + checkout - packagist.org 上发布的稳定版 → 下载 zip/tar 并解压
- 通过
composer link创建的链接 → 那是另一套机制，不走 config.symlink 控制
真正要小心的是：一旦你依赖某个包的 path 版本做了开发，又不小心在 CI 或新机器上跑了没删 vendor 的 composer install，而那里没开 symlink 或环境不支持，就会悄悄变成 copy —— 表面正常，实则热更新失效。验证必须落到 ls -la 这一行命令上，而不是看有没有报错。
