Composer默认不走符号链接是因为为保证可重现性而采用复制策略；需在主项目composer.json的require中为依赖显式添加"symlink": true，并确保path仓库定义在主项目中、路径正确且目标包composer.json的name与require一致。
path仓库配置后为什么composer install不走符号链接？
默认情况下，Composer 对 path 类型仓库的处理是「复制」而非「软链」——哪怕你本地改了包代码，vendor/ 里还是旧副本。这是为了保证可重现性，但本地开发时反而成了障碍。
必须显式启用 symlink 模式才能让 Composer 把包目录直接软链接进 vendor/，否则改了源码得反复 composer update 才生效，效率极低。
- 在
composer.json的根项目中，为该依赖添加"symlink": true字段（不是在仓库定义里） - 确保目标路径是绝对路径，或相对于当前
composer.json的相对路径（推荐用../my-package这种） - 执行
composer update vendor/package-name，不是install——install只读composer.lock，不会触发 symlink 逻辑
如何写一个能被 symlink 正确识别的 path 仓库定义？
很多人把 repositories 写在包自己的 composer.json 里，其实没用——主项目的 composer.json 才是唯一生效位置。而且路径必须真实存在、有合法 composer.json，否则 Composer 会静默跳过。
- 在主项目的
composer.json中添加："repositories": [ { "type": "path", "url": "../my-local-package" } ] -
url值不能以./开头（Composer 不解析），建议用../或绝对路径如/Users/me/projects/my-package - 目标目录下的
composer.json必须包含"name"，且和主项目require中写的完全一致（包括 vendor 名） - 如果目标包用了
autoload-dev或特殊 PSR-4 映射，确保它本身能被正常加载——symlink 只解决路径问题，不修复自动加载错误
symlink 后修改包代码却没生效？检查这些点
软链建好了，但改了包里的 PHP 文件，运行时还是旧逻辑——大概率是 OPcache 或 Composer 自动加载缓存没清。
- 运行
composer dump-autoload（尤其当你改了包里的类名或命名空间映射） - PHP CLI 环境下记得关 OPcache：
opcache.enable_cli=0，否则php -f test.php会缓存旧字节码 - Web 服务器（如 Apache/Nginx + PHP-FPM）需重启 FPM 进程，或清空 OPcache Web 页面（如果有）
- 确认软链确实存在：
ls -la vendor/vendor-name/package-name，输出应是... -> /absolute/path/to/my-local-package，而不是普通文件夹
Windows 下 symlink 需要额外权限和配置
Win10/11 默认禁用开发者模式时，mklink 权限受限，Composer 创建 symlink 会失败并回退到 copy，但不报错——这会让你以为配置生效了，实际还是复制。
- 以管理员身份运行终端（CMD/PowerShell），再执行
composer update - 或开启「开发者模式」：设置 → 更新与安全 → 针对开发人员 → 开启「开发者模式」
- Git Bash 不支持原生 symlink（除非用
git config core.symlinks true并重置工作区），建议直接用 Windows Terminal + PowerShell - 检查 Composer 是否真的用了 symlink：看
vendor/下对应目录是否显示为「快捷方式」图标（GUI）或ls -la输出含->
symlink 联动真正起效的前提，是整个链路没有被缓存、权限、路径解析或配置层级打断——任何一个环节卡住，都会退化成手动 copy 调试，而这个退化过程往往悄无声息。
