必须提交composer.lock到Git，它是依赖树的精确快照，记录各包版本、校验和及安装方式；无它则composer install退化为update，导致各环境vendor目录不一致。
靠composer.lock文件 + 强制install + 禁止随意update，就能让所有人的vendor/目录内容完全一致。其他花哨配置都是锦上添花，这个组合才是底线。
为什么必须提交composer.lock到 Git
它不是“可选附件”，而是依赖树的快照：记录了每个包（包括二级、三级依赖）的精确版本、校验和、安装方式。没有它，composer install就退化成composer update——每个人跑一遍，得到的vendor/可能完全不同。
- 新成员克隆项目后只运行
composer install，就能还原出和 CI、线上一模一样的依赖结构 - CI 流程中若用
composer update，等于放任环境漂移；必须用composer install -
composer.lock被修改时，应视为一次实质性的环境变更，需走代码评审
团队里谁可以执行composer update
不能是“谁想升就升”。升级依赖本质是引入不确定风险，必须有人兜底。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 由专人（如 Tech Lead 或 Infra 组成员）发起升级，明确说明升级原因（安全补丁？功能需求？）
- 升级前先跑
composer outdated，确认哪些包真正需要动，避免全量更新 - 升级后必须完整回归测试（单元、集成、关键路径），通过后再提交新的
composer.lock - 禁止在 PR 中混入
composer.lock变更和业务代码——拆成两个 PR，先锁环境，再改逻辑
require和require-dev必须严格区分
不加区分会导致生产环境意外加载开发工具，或测试环境缺失必要组件。
-
require只放运行时必需的包，比如monolog/monolog、guzzlehttp/guzzle -
require-dev放测试、格式化、静态分析等工具，比如phpunit/phpunit、friendsofphp/php-cs-fixer - 部署到生产时，必须加
--no-dev --optimize-autoloader参数，否则require-dev里的包也会被装进去 - CI 脚本里要显式声明
COMPOSER_NO_DEV=0或1，避免因环境变量默认值不同导致行为不一致
最容易被忽略的点：platform 配置不传递
"config": {"platform": {"php": "8.2.10"}}只约束当前项目的install行为，不会覆盖子依赖自身声明的 PHP 版本要求。比如你锁了 PHP 8.2，但项目依赖的某个包在自己的composer.json里写了"php": "^8.3"，Composer 仍会拒绝安装——它优先尊重子依赖的声明。
这意味着：团队统一 PHP 版本不能只靠platform，还得配合 Dockerfile / README 明确标注最低 PHP 要求，并在 CI 中用php -v做前置校验。否则，composer install可能在某台机器上静默失败，而错误信息藏在嵌套依赖的兼容性检查里，极难定位。
