用../my-package相对路径更可靠，因其以主项目composer.json所在目录为基准，避免跨平台、ci环境及权限导致的绝对路径失效问题。
为什么用../my-package相对路径比绝对路径更可靠
相对路径以主项目composer.json所在目录为基准，换机器、换用户、CI 环境迁移时不会因/Users/xxx或C:\dev\失效。绝对路径看似直观，但 Windows 权限问题、Mac/Linux 用户目录差异、CI 容器无固定路径，都会导致composer install静默 fallback 到复制模式，失去热更新能力。
必须满足三个硬性条件：
-
url值必须是双引号包裹的字符串，例如"../my-package"，不能写成../my-package（JSON 解析失败） - 路径只能以
./或../开头，不支持~/、$HOME/或file://协议 - 该路径下必须存在合法的
composer.json（无尾逗号、全双引号、语法有效），且该文件里有"name"字段，格式如"acme/utils"（小写字母+短横线，不含空格或下划线）
composer.json里repositories配置写在哪、怎么写才生效
它必须是项目根目录composer.json的顶层字段，不能嵌在require、config或scripts里。常见错误是把它塞进config.repositories——Composer 完全忽略。
正确结构示例：
{
"repositories": [
{
"type": "path",
"url": "../my-package"
}
],
"require": {
"acme/my-package": "dev-main"
}
}
注意：url指向的是**目录**，不是composer.json文件本身；require中的包名必须和../my-package/composer.json里的"name"字段完全一致（大小写、分隔符、vendor 名一个都不能错）。
为什么vendor/acme/my-package是文件夹而不是符号链接
这说明 symlink 没启用，或者被系统/权限/配置拦截了。Composer 的 path 类型仓库默认行为就是创建符号链接，但前提是：
- 本地包自己的
composer.json里声明了"options": {"symlink": true}（不是主项目的配置） - 主项目没全局或本地禁用：
composer config symlinks false或composer config --global symlinks false - Linux/macOS 下普通用户默认支持；Windows 需启用“开发者模式”或以管理员身份运行终端（否则
mklink /D失败，Composer 静默回退到拷贝） - 路径权限足够：目标目录可读写，且父目录允许创建符号链接
验证方式：ls -l vendor/acme/my-package（macOS/Linux）或 dir vendor\acme\my-package（Windows），看到->或<symlinkd></symlinkd>才是链接成功。
改了本地包代码，项目里不生效？检查这三处
这是最常被忽略的静默失败点，现象是反复composer update也没用——因为根本不需要重装，链接已存在，只是没命中或没加载。
- 本地包
composer.json的"version"字段是否与require中版本约束严格匹配？例如写了"version": "dev-main"，就需"acme/my-package": "dev-main"，不能写"*"或"^1.0" - 主项目
minimum-stability是否为"dev"？如果本地包version是"dev-main"，而主项目没设"minimum-stability": "dev"，Composer 直接跳过该版本 - 本地包是否已
git init并至少有一个 commit？Composer 要求 path 仓库目录是 Git 仓库（哪怕没远程 origin），否则拒绝解析，报Could not find package
真正起作用的从来不是composer require命令本身，而是repositories声明 + name/version对齐 + symlink启用这三者的协同。少一个，../my-package就只是硬盘上一个普通文件夹，不是开发源。
