推荐使用 Composer 的 path 仓库方式管理跨项目本地共享库，通过配置 "repositories" 为 path 类型并启用 "symlink": true，使 vendor 中的包符号链接至本地源码，确保修改即时生效且可复现；手动 symlink 方式存在被覆盖、autoload 失效等风险，仅适用于临时调试。
用 Composer 管理跨项目的本地共享库，核心是让多个项目能直接引用你本地开发中的库代码，且无需反复 install/push/pull。最实用、最轻量的两种方式是：path 仓库（推荐） 和 软链接（symlink，需谨慎）。前者更稳定、可复现；后者适合极快速调试，但容易出环境问题。
用 path 仓库实现本地库自动映射
这是官方推荐、项目间协作友好的方式。Composer 会把本地路径当作一个“虚拟包仓库”，只要路径下有合法的 composer.json，就能被其他项目 require 并自动 symlink 到 vendor/ 中（前提是启用了 local repos 和 path 类型）。
- 在你的本地库目录（如
~/code/my-shared-lib）中确保有完整composer.json，包含"name"（如"acme/shared-lib"）、"version"（如"dev-main"或"1.0.x-dev"）等基础字段 - 在使用该项目的主应用的
composer.json中添加：
"repositories": [
{
"type": "path",
"url": "../my-shared-lib",
"options": {
"symlink": true
}
}
],
"require": {
"acme/shared-lib": "dev-main"
}
- 运行
composer update acme/shared-lib，Composer 会创建符号链接（不是复制），修改库代码后主项目立即可见 -
"symlink": true是关键——它让 vendor 中的包指向源码目录；若设为false，则会复制一份（不推荐用于开发） - 该配置可提交到 Git，团队成员只要本地有对应路径，就能一键启用（路径可相对，也可用环境变量如
${HOME}/code/...）
手动 symlink 的适用场景与风险
不通过 Composer 配置，而是手动在 vendor/ 下建 symlink，仅建议用于临时验证或 CI 调试，不适合日常开发或协作。
- 先
composer install正常引入包（比如从 Packagist 安装一次），再删掉vendor/acme/shared-lib - 执行：
ln -s ~/code/my-shared-lib vendor/acme/shared-lib（macOS/Linux）或mklink /D vendor\acme\shared-lib C:\code\my-shared-lib（Windows） - 问题明显：Composer 不知情，
composer update可能覆盖 symlink；composer dump-autoload有时不识别新结构；IDE 可能无法正确解析依赖路径 - 如果必须用，建议配合
composer.json的"autoload-dev"+post-update-cmd脚本自动重建链接（但复杂度已接近 path 仓库方案）
避免常见坑的几个细节
-
版本号要匹配：本地库的
"version"必须和主项目require的约束一致，例如写"dev-main"就不能在库中写"1.0.0"，否则 Composer 找不到匹配项 -
路径必须绝对或相对于主项目根目录：path 仓库的
"url"是相对于主项目composer.json的位置，不要用~/（除非 Composer 支持 shell 展开，实际多数不支持） -
别忽略 autoload：本地库的
composer.json必须正确定义"autoload"（如"psr-4"），否则即使链接成功，类也加载不了 -
CI/CD 中禁用 path 仓库：生产构建时应移除或注释掉
repositories中的path条目，改用 packagist 或私有仓库，保证可重现性
基本上就这些。path 仓库方式不复杂但容易忽略 "symlink": true 和版本对齐，用好它，本地多项目联调就变得很顺。
