Composer在大型多人协作项目中如何规范公共基础库的代码审核（包管理）-composer-PHP中文网

公共基础库引入必须走评审流程，需提交github主页、活跃度及cve检查，明确动机并双签确认；禁止使用dev分支，minimum-stability设为stable；依赖变更须同步提交composer.json和.lock文件；多项目复用应通过语义化版本或私有packagist；ci中需定时执行composer outdated并告警。

composer在大型多人协作项目中如何规范公共基础库的代码审核（包管理）

公共基础库的引入必须走评审流程，不能直接 `composer require`

团队里有人随手 composer require myorg/utils，结果没过安全扫描、没测兼容性、没看 changelog，上线后引发 autoload 冲突或行为变更。这不是技术问题，是流程缺口。

所有 require 或 require-dev 新包，必须满足三个条件才允许合并：

提交 PR 时附带该包的 GitHub 主页、最近 3 个月 commit 活跃度、是否有已知 CVE（可用 composer audit 或 security:check 插件）
明确说明引入动机（例如：“替换自研日志封装，因 monolog 支持 PSR-3 且维护活跃”）
由至少一名核心成员 + 一名安全/架构角色双签确认，而非仅“+1”了事

特别注意：dev-main、dev-develop 这类分支约束禁止出现在 require 中；minimum-stability 必须设为 stable，prefer-stable 设为 true，否则 composer update 可能悄悄拉下 unstable 版本。

基础库版本升级必须原子化提交 `composer.lock`

常见错误是：A 同学执行 composer update myorg/utils，只提交了 composer.json，B 同学本地 composer install 时发现 vendor/ 里类文件路径不对——因为 lock 文件没同步，autoload 映射失效。

正确做法只有一条：任何依赖变更，必须同时提交 composer.json 和 composer.lock，且 CI 流水线要校验二者一致性（可用 composer validate --strict）。

升级操作本身应由专人执行，并遵循：

Discussion Composer

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

下载

先在独立分支运行 composer update myorg/utils --with-dependencies，观察是否连带升级其他包
跑全量测试（含集成测试），尤其检查跨服务调用链中该库被消费的边界场景
生成新 composer.lock 后，用 git diff 确认只改了预期行，没有意外变更其他包版本

多项目复用同一基础库，别用 `path` 仓库搞本地开发

path 类型仓库在本地联调时确实方便，但它的硬伤是：CI 构建时路径不存在，Docker 构建失败，GitLab Runner 报 Could not find package —— 因为 ../user-sdk 在容器里根本不存在。

真正可落地的方案只有两个：

基础库发版走语义化版本（如 1.3.2），所有业务项目统一写 "myorg/utils": "^1.3"，靠 composer.lock 锁定具体小版本
内部私有 Packagist（如 Satis 或 Private Packagist）托管所有基础库，确保所有环境走同一源，镜像地址统一配置在 composer config -g repo.packagist

如果非要本地调试，临时加 path 可以，但必须：