Composer在composer.lock中完整记录path仓库包的name、version、source.type为path及source.url（相对或绝对路径），install时严格校验该路径存在且可读，路径失效则中断安装，不回退到Packagist。

path仓库的依赖在composer.lock里怎么存

Composer 对 path 类型仓库（如 "repositories": [{"type": "path", "url": "./packages/my-package"}]）的处理是特殊的：它不走远程下载，而是直接 symlink 或 copy 本地目录。但关键点在于，composer.lock 仍会完整记录该包——包括它的 name、version、source.type（值为 path），以及 source.url（即你配置的相对路径）。这个路径被固化进 lock 文件，后续 composer install 会严格校验它是否存在、是否可读。

删了 vendor 后用 install 能否恢复 path 包

不能依赖自动恢复，必须确保路径始终有效：

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

• 如果 source.url 是相对路径（如 ./packages/foo），那么执行 composer install 的工作目录必须和生成 lock 时一致，否则会报 Source path ./packages/foo is not found
• 绝对路径虽可避免相对性问题，但彻底牺牲可移植性——CI 或队友机器上根本不存在该路径，install 必然失败
• composer install 不会“猜”或“fallback”到 Packagist；它只认 lock 里写的 source.url，路径不对就中断，不尝试联网拉取同名包

换环境或 CI 中怎么安全用 path 仓库

核心原则：path 仅用于开发联调，绝不能进入构建流水线。

• CI 脚本中必须移除或禁用 path 类型仓库配置（例如通过 composer config --unset repositories 或用不同 composer.json 变体）
• 团队约定：所有 path 依赖必须有对应的真实 Packagist 或私有源发布版本，且 composer.json 中的 require 字段应指向该正式版本（如 "myvendor/mypackage": "dev-main as 1.0.0"），而非仅靠 path 临时顶替
• 若真需在 CI 中测试本地修改，应改用 composer require --dev myvendor/mypackage:dev-main --repository-url=https://your-satis.example.com，再 composer update 生成新 lock，而不是保留 path 配置

合并冲突时 path 相关字段能不能手动改

绝对不要手动编辑 composer.lock 里的 source.url 或 source.type。

• 任意修改都会破坏 content-hash 校验，导致后续 composer install 报 Your lock file does not contain a compatible set of packages
• Git 冲突时，正确做法是先统一 composer.json 中的 repositories 配置，然后删掉 composer.lock 和 vendor/，再跑 composer update 重生成——让 Composer 自己决定当前上下文该用哪个源、哪个路径
• 尤其注意：两个分支一个配了 path，一个没配，合并后若保留了 path 条目但没同步本地目录结构，lock 文件就变成“合法但不可用”的状态

路径有效性是 runtime 级别的约束，不是配置层面的提示。一旦 lock 文件里写了 ./packages/bar，它就不是“建议”，而是安装时的硬性检查点。