composer锁定依赖需同时满足：composer.json写三位精确版本号、提交composer.lock到git、部署时运行composer install；缺一不可，否则会退化为隐式update导致环境不一致。
生产环境依赖失控，八成不是包本身更新快，而是你没真正锁住——composer.lock 没提交、composer install 没跑对、镜像源没全局生效，三者缺一就会退化成隐式 update。
composer install 为什么没锁定？先查这三件事
命令返回 0 不代表锁住了。常见现象是部署完 vendor 缺类、运行时报 Class not found，但日志里没报错。
-
ls -l composer.lock输出为空或被.gitignore忽略了——没有 lock 文件，install就自动 fallback 到update -
composer install执行时出现Resolving dependencies日志——说明它正在重新算版本，根本没读 lock -
git status显示composer.lock已修改但未提交——团队成员拉代码后跑install，实际装的是各自本地解析出的版本
怎么让 composer.lock 真正起作用？必须做这三步
lock 文件不是“存在就行”，它得和命令、环境匹配才生效。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 改完
composer.json（比如加了个包）后，必须手动运行composer update vendor/package-name或composer update，再git add composer.lock提交——否则 lock 里没记录新包，部署时会直接失败 - CI/CD 构建脚本开头加一句
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，避免缓存旧配置导致拉包超时或 404 - 生产部署命令必须是
composer install --no-dev --no-scripts --no-autoloader --optimize-autoloader --no-interaction，别省参数——--no-scripts防止 ThinkPHP 的 post-install 清空 runtime，--no-autoloader是为了后续单独dump-autoload -o控制时机
想锁死某个包不升级？别靠 ^ 或 ~
写 "monolog/monolog": "^2.11" 或 "monolog/monolog": "2.11.*" 都不算锁定，补丁更新照样进。
- 精确锁定只有一种写法：
"monolog/monolog": "2.11.0"——三位全写，不带任何符号，Composer 才认作 exact version - 改完立刻运行
composer update monolog/monolog，否则composer.lock不会同步更新，等于白改 - 如果该包已装新版，想降级到旧版，用
composer require monolog/monolog:2.11.0（冒号后无空格、无 v、无 @），然后删掉vendor/monolog/monolog和composer.lock里对应条目再重装，避免缓存干扰
PHP 版本变了，lock 文件可能失效
Composer 2.0+ 默认校验 platform 字段，不是“能跑就行”，而是“版本字节级一致”。
-
composer.json里加"config": {"platform": {"php": "8.2.12"}}，写死小版本，别只写"8.2" - 上线前在服务器上跑
php -v和composer show --platform，确认 PHP 实际版本和 lock 文件里记录的完全一致 - 扩展也要对齐：
ext-gd、ext-mbstring这些在composer.json的require里写了，就得确保php -m | grep gd有输出，否则install直接退出
最易被忽略的点：镜像源只是加速，真正决定稳定性的，是 composer.lock 是否存在、是否提交、是否与 composer.json 语义一致，以及部署时是否真的执行了 install 而不是被悄悄替换成 update。
