path仓库配合"symlink": true是Composer唯一可控的本地开发与线上环境隔离方案，需在本地包composer.json中配置、用composer update触发、通过ls -la验证->符号。
path仓库 + symlink: true 是唯一可控方式
想用软链接隔离开发环境（改本地包）和正式依赖（线上装稳定版），必须用 type: "path" 仓库配合全局 symlink 开关。这不是“可选技巧”，而是 Composer 唯一支持的、能同时满足「实时感知本地修改」和「不污染正式 vendor 结构」的路径。
操作分三步：在主项目 composer.json 的 repositories 块里加 path 源 → 把 require 中的版本号换成 dev-main（或对应分支）→ 运行 composer update vendor/name。
-
url必须是相对于主项目根目录的相对路径，比如"../my-package"，不能写~/my-package或绝对路径 - 目标目录下必须有合法的
composer.json，否则报Could not parse version constraint - 改完后
vendor/vendor/name会变成指向本地目录的符号链接，ls -la可见->符号
为什么 composer link 不适合环境隔离
composer link 是个“事后补丁”，只对已安装包生效，且不写入 composer.lock，也不触发 autoload 重生成。它无法区分开发/正式环境，一旦执行 composer update，链接大概率被覆盖回硬拷贝。
- 必须先
composer require vendor/name安装一次，再进本地包目录运行composer link - 回到主项目后，得再跑
composer link vendor/name，缺一步都不行 - CI 构建或换机器重装时，这个链接完全丢失，无法复现
- 它绕过版本约束，但同时也绕过了 Composer 的依赖解析逻辑，容易引发
Class not found
symlink: true 被静默降级怎么办
尤其在 Windows 上，symlink: true 很可能因权限不足而 fallback 到硬复制，且默认不报错。你以为在链，其实只是 copy。
- 加
-v参数重跑命令：composer update -v，搜索输出里的falling back to copy - 确认当前终端是否以管理员身份运行（CMD/PowerShell）
- 手动测试系统能力：
cmd /c mklink /D test-link .，失败说明系统策略禁用了 symlink - 若确定不支持 symlink，就别配
"symlink": true，否则预期与实际不符
硬复制模式下怎么临时调试本地变更
如果环境不支持 symlink，又不想每次改完都 composer update，可以用 autoload-dev + 手动符号链接绕过 vendor 加载。
- 在主项目
composer.json的autoload-dev里加 PSR-4 映射："MyVendor\MyPackage\": "../my-package/src/" - 然后在终端执行：
ln -sf ../my-package/src/ src/MyPackage（Linux/macOS）或用mklink /D（Windows） - 最后运行
composer dump-autoload生效 - 注意：这仅影响自动加载，不解决 bin 文件、依赖传递等 vendor 级行为
真正容易被忽略的是：path 仓库的 symlink 行为只在首次安装或 composer update 时生效；如果 vendor 里已有硬拷贝目录，Composer 不会自动把它转成链接——必须先删掉对应目录再重装。
