必须提交 composer.lock 且所有环境统一执行 composer install；禁止随意 run composer update；require 与 require-dev 须严格区分；禁用不稳定版本；platform 需显式约束以保障环境一致性。
必须提交，且所有环境统一执行—— 这是规范的底线，其他都是围绕它展开的细节。
为什么不能让团队随意运行
开发机上随手
会生成新
，但没人验证过这个新版本组合是否通过全部测试。CI 流水线若仍用旧 lock 文件部署，就可能出现“本地能跑、线上报错”的经典问题。
CI/CD 中必须用
，禁用
（可在脚本里加
防误触）
升级依赖只能由专人操作：先
单独更新，再跑全量测试，确认无误后提交新
Git 提交前建议加钩子检查：
和
必须严格区分
把 PHPUnit 放进
，会导致生产环境多装几十 MB 无关代码；反过来把 Guzzle 放进
，则线上发 HTTP 请求直接失败 —— 这类错误在灰度发布时才暴露，代价极高。
：仅放运行时真正需要的包（如
、
）
：只放开发/测试工具（如
、
）
CI 构建时可加
参数跳过 dev 包，减小镜像体积和攻击面
上线前用
快速核对 dev 包是否意外混入
如何防止不稳定版本污染生产环境
写
或
看似方便，实则等于放弃版本控制。Packagist 上大量
分支无人维护，某天作者删库或改接口，你的服务就挂了。
Composer 2.9.6
Composer 2.9.6 是 PHP 生态中高效、稳定的依赖管理工具。此版本在性能与兼容性上进一步优化，改进了依赖解析算法，提升大型项目中的安装与更新速度。它支持并行下载任务，显著减少等待时间，并增强了与私有仓库及镜像源的交互稳定性。同时修复了多项命令行交互与内存使用相关的缺陷，确保在复杂依赖关系下依然可靠运行。无论是新项目初始化还是现有系统维护，Composer 2.9.6 都能为开发者提供流畅、精准的依赖管理体验。
下载
在
顶层强制声明：
，
禁止在
中出现
、
、
标签（
中允许，但需备注原因）
CI 中加入检查：
会报错不合规的稳定性标签
安全扫描必须定期跑：
（PHP 8.1+ 内置）或
配置常被忽略，但它决定能否构建成功
本地 PHP 8.2 能跑的项目，到了线上 PHP 8.1 服务器上
直接失败 —— 因为某个依赖悄悄要求
，而
没显式约束平台版本。
在
的
下硬编码目标环境版本：
这会让 Composer 在解析依赖时，假装当前 PHP 是 8.1.10，从而避开要求更高版本的包
避免使用
或模糊范围（如
），精确到 patch 版本更稳妥
搭配
命令，上线前快速验证环境兼容性
真正难的不是写几条规则，而是让每条
都经过评审、每次
变更都附带测试报告、每个
配置都和线上真实环境对齐 —— 这些细节不落地，规范就只是文档里的装饰文字。
composer.lockcomposer installcomposer updatecomposer updatecomposer.lockcomposer installupdate--no-interaction --no-scriptscomposer update vendor/package-namecomposer.lockgit diff --quiet composer.lock || echo "lock changed: please verify"requirerequire-devrequirerequire-devrequiremonolog/monologguzzlehttp/guzzlerequire-devphpunit/phpunitphpstan/phpstan--no-devcomposer show --dev"monolog/monolog": "dev-main""^2.0@dev"dev-composer.json"minimum-stability": "stable""prefer-stable": truerequire@dev@alpha@betarequire-devcomposer validate --strictcomposer auditcomposer outdated --direct --minor-onlyplatformcomposer installphp:^8.2composer.jsoncomposer.jsonconfig.platform"php": "8.1.10"*^8.1composer check-platform-reqscomposer requirecomposer.lockplatform