Composer测试环境软链接首选path仓库类型：在主项目composer.json中配置repositories指向本地包相对路径，require中用dev-main等分支别名，再composer update包名即可生成指向本地目录的符号链接。
Composer 测试环境做软链接，核心就两条路：用 path 仓库类型指向本地包目录（推荐），或对已安装包执行 composer link（慎用）。前者可复现、不污染 lock 文件；后者快但容易被后续 composer update 覆盖，且不更新自动加载映射。
用 path 仓库让本地包实时生效
这是开发调试阶段最稳的方式，适用于你正在改一个本地包（比如 ../my-utils），又希望主项目立刻读到改动，而不是等发版再 require。
- 在主项目的
composer.json顶部加repositories块，url必须是相对于项目根目录的相对路径（如"../my-utils"），不能用~/或绝对路径 -
require里把版本号换成分支别名，例如"vendor/my-utils": "dev-main"（不是"^1.0"） - 运行
composer update vendor/my-utils—— 注意一定要带包名，否则可能误更新其他依赖 - 完成后
vendor/vendor/my-utils会变成符号链接，指向你指定的本地目录 - ⚠️ 若报
Could not parse version constraint，大概率是本地包目录下没有合法的composer.json，或者里面缺name和version字段
composer link 只适合已安装包的临时验证
composer link 不是通用解决方案，它只对「已经通过 composer require 安装进 vendor/ 的包」起作用。本质是在 vendor/ 下建软链接，绕过版本约束，但不会同步 autoload、也不会写入 composer.lock。
- 先确保包已安装：
composer require vendor/name - 进该包的本地源码目录（不是主项目目录），运行
composer link（需 Composer 2.4+ 或已装composer-plugin-link） - 回到主项目目录，再运行一次
composer link vendor/name，才会在vendor/下生成链接 - ⚠️ 后续只要执行
composer update（哪怕不带参数），这个链接大概率被删掉，换回从 packagist 拉的 zip 包 - ⚠️ 如果改了本地包的类名或命名空间，
autoload不会自动刷新，得手动跑composer dump-autoload
常见失败现象和排查点
软链接看似简单，但在实际操作中卡住的地方往往很隐蔽：
- 报
failed to open stream: No such file or directory：检查本地包目录下的composer.json是否有语法错误，特别是末尾多逗号、引号不闭合 - 链接建成了但代码没更新：确认你改的是链接目标目录里的文件，而不是
vendor/下原来那个被覆盖的副本 - PHP 报
Class not found：不是链接问题，是 autoloader 没重载，执行composer dump-autoload -o强制重建优化后的映射 - CI/CD 环境里链接失效：
path类型仓库默认被禁用（出于安全考虑），需显式加--with-all-dependencies或在config里设"allow-plugins": {"composer/installers": true}
真正麻烦的从来不是命令怎么敲，而是链接建好了，你改了三行代码却还在用旧逻辑——这时候要盯住 vendor/ 目录下的符号链接是否真的指向你认为的那个路径，以及 composer dump-autoload 有没有被执行。
