公共基础库引入必须走评审流程，需提交GitHub主页、活跃度及CVE检查，明确动机并双签确认；禁止使用dev分支，minimum-stability设为stable；依赖变更须同步提交composer.json和.lock文件；多项目复用应通过语义化版本或私有Packagist；CI中需定时执行composer outdated并告警。
公共基础库的引入必须走评审流程，不能直接 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）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “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 可以，但必须：
- 加
// @dev-only注释标记，CI 脚本自动跳过该段配置 - 上线前手动删掉
repositories块，换回私有源地址 -
composer install成功后立即git status确认没残留path配置
composer outdated 不是“看看就行”，得进 CI 告警
很多团队把 composer outdated 当成手动巡检动作，结果三个月没人跑一次，等出安全漏洞才翻记录。这等于把风险敞口留给了人肉记忆力。
建议在 CI 中加入定时任务（如每周一凌晨）：
- 运行
composer outdated --direct --format=json，解析输出判断是否有security标记的包 - 若有，触发企业微信/钉钉告警，@对应模块负责人，并附上
composer audit详情链接 - 对长期未更新的基础库（如 >90 天无新版），自动创建 GitHub Issue，标题带
[STALE]前缀，强制进入技术债看板
最易被忽略的是：基础库自身也依赖其他包，outdated 默认不显示 transitive 依赖。真要查透，得加 --all 参数，但代价是 CI 时间变长——权衡点在于，你更怕漏掉一个高危 CVE，还是怕构建慢 2 分钟。
