path仓库天生不适合模拟线上环境，因其跳过远程校验、依赖本地路径、不生成标准lock source条目，且上线时必须移除；应改用vcs仓库+git分支/tag方案。
不能模拟线上依赖环境——path仓库是开发期专用机制，上线时必须移除或禁用。 它的设计目标就是绕过Packagist、跳过版本约束、直连本地文件系统，和“模拟线上”完全背道而驰。
为什么path仓库天生就不适合模拟线上环境
Composer 的 path 类型仓库在解析时会直接跳过所有远程元数据校验（比如版本可用性、签名、哈希比对），也不走 composer.lock 中记录的 source 信息。它只认两件事：url 指向的目录是否存在、该目录下是否有合法的 composer.json。这意味着：
- 你本地改了
composer.json里的version字段，线上环境根本不会识别——因为线上不读你本地那个文件 -
composer install在 CI 或 Docker 中执行时，../my-pkg路径大概率不存在，直接报Could not find package vendor/name - 即使路径存在，若未启用
symlink，vendor/里是副本而非源码，类加载路径和线上不一致，Xdebug 断点位置错位 - lock 文件中该包的
source条目会显示为"type": "path"，而标准线上流程要求是"type": "git"或"dist"
真正能“模拟线上”的替代方案
想让本地行为尽可能贴近线上，应放弃 path，改用以下方式：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 用
vcs类型仓库指向你自己的 Git 仓库（如"type": "vcs", "url": "https://gitlab.internal/vendor/pkg.git"），再通过require指定分支或 tag（如"dev-main"或"1.2.0"） - 本地开发时，把该 Git 仓库克隆到项目旁，用
git worktree或git --git-dir切换分支，保持与composer.json中声明的版本一致 - CI 环境中确保该 Git 仓库可访问，并配置好 SSH key 或 token；Docker 构建时用
git clone预拉取，避免 runtime 依赖网络 - 如果必须用本地代码调试，只在
require后临时加repositories，且提交前手动删掉——别让它进 git 历史
path仓库唯一靠谱的“类线上”用法：离线预验证
它唯一接近线上价值的场景，是提前验证某个尚未发布的包能否被正常安装和 autoload，但前提是：
- 本地包目录已完整
git init && git add . && git commit -m "for testing"，且有dev-main分支 - 主项目
composer.json中require写的是"vendor/name": "dev-main"，不是"*"或"^1.0" - 运行
composer update vendor/name --with-dependencies后，立刻删掉repositories段，再跑一次composer install看是否仍能成功 - 检查生成的
composer.lock，确认该包的source已变成"type": "git"，且reference是真实 commit hash
最常被忽略的一点：path 仓库不会触发 autoload 映射的自动重载。哪怕 symlink 成功、代码也实时更新了，如果本地包的 composer.json 中 autoload 规则变了，你必须手动执行 composer dump-autoload -o，否则 Class not found 错误照常发生。
