必须在主项目composer.json的repositories中配置{"type":"path","url":"../my-package"}，本地包需有合法composer.json且name与require一致，版本用dev-main，路径用相对路径。
composer require 时强制走本地 path 仓库
想让 composer require 不从 Packagist 下载，而是直接软链接到你改着的本地包？关键不是加参数，而是提前配好 repositories 并用开发分支名代替版本号。
常见错误是运行 composer require vendor/name:dev-main 却还是下载 zip 包——因为没声明本地源，Composer 根本不知道 dev-main 指向哪。
- 在主项目
composer.json的顶部加repositories块（必须是数组，且type为path）："repositories": [ { "type": "path", "url": "../my-package" } ] -
url必须是相对路径（相对于主项目根目录），不能以~/或/home/开头；目标目录下必须有合法的composer.json，否则报Could not parse version constraint - 执行
composer require vendor/name:dev-main（注意冒号后是分支名，不是1.0.x-dev这类别名） - 成功后
vendor/vendor/name会变成符号链接，指向你指定的../my-package
composer link 命令只对已安装包生效
composer link 不是通用软链接开关，它只作用于「已经通过 Composer 安装进 vendor 的包」，本质是覆盖已有目录为软链，不改 composer.lock，也不触发 autoload 重生成。
典型误用：先 composer remove vendor/name，再 composer link vendor/name → 报错 Package vendor/name is not installed。
- 必须先确保包已存在
vendor/下：composer require vendor/name（哪怕只装个空版本） - 进入本地包目录，运行
composer link（要求 Composer ≥2.4 或已装composer-plugin-link） - 回到主项目，运行
composer link vendor/name，此时才真正建立软链 - 后续若执行
composer update，这个软链会被删掉并替换成正常安装包——这是它最危险的地方
--prefer-source 和 --no-cache 对软链接无效
有人试过加 --prefer-source 或 --no-cache 想“逼” Composer 用 git 克隆而非 zip，但这跟软链接完全无关。这两个参数只影响远程包的获取方式，对 path 类型仓库不起作用，也控制不了 composer link 行为。
真正决定是否走软链的，只有两件事：仓库类型是否为 path，以及 require 的版本约束是否匹配本地包的分支或别名。
-
path仓库下，dev-main、dev-develop、dev-feature/x都能命中；但^1.0、1.0.0这类稳定版本号不会 - 如果本地包
composer.json里写的是"version": "1.0.0"，那即使url指向它，require里写"dev-main"也会失败——版本字段和分支名必须一致或兼容
权限与路径错误导致软链接静默失败
宝塔或某些 Linux 环境下，vendor 目录被 web 服务器用户（如 www）拥有，而你用 root 或其他用户跑 composer，可能导致符号链接创建失败但无提示，最终 vendor 里留了个空目录或普通文件。
验证是否真成了软链，别只看 ls -l vendor/，要进 vendor/vendor/name 执行：readlink -f . —— 如果输出为空或报错，说明没链上。
- 确保运行
composer的用户对主项目根目录、vendor目录、本地包目录都有读写权限 - 宝塔用户尤其注意：PHP 禁用函数里必须删掉
proc_open和putenv，否则composer update卡住或报 fork failed，软链根本走不到最后一步 - Windows 下
path仓库仍可用，但符号链接需管理员权限启用，且部分 IDE 可能无法正确解析跳转
