composer install本质是按composer.lock精确还原环境的确定性操作，非“安装命令”；若lock缺失、被忽略、未提交或配置错误，它会退化为update导致环境漂移。
生产环境不推荐使用带修改性质的 composer install 命令，是因为它根本就不是“安装命令”，而是“还原命令”——只要它开始改东西（比如生成新 composer.lock、跳过 platform 检查、重写 vendor/autoload.php），就说明你已经脱离了可验证、可回滚的部署前提。
为什么 composer install 会变成“修改行为”？
它本不该修改任何东西，但以下情况会让它悄悄退化为 composer update：
-
composer.lock文件缺失、被.gitignore错误排除，或未提交到 Git —— 此时install会自动 fallback 到全量解析依赖 - 执行时加了
--no-lock（虽已废弃，但旧 CI 脚本里仍有残留） - 本地
composer.json被手动改过（比如多了一个空格、换了一行注释），导致 hash 不匹配，Composer 拒绝复原而强制重算 -
config.platform写在错误位置（如嵌套在require下），或值不具体（如写"php": "8.1"而非"8.1.10"），导致 platform 假设失效，实际解析时按运行环境 PHP 版本去选包
composer install --ignore-platform-reqs 看似能过，实则埋雷
这个参数不会让安装变“安全”，只会让错误延后爆发：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 它绕过了
composer.lock中记录的 PHP 版本、扩展依赖等约束，可能装进一个根本跑不起来的包（比如要求ext-gmp却没启用） - 装完看似成功，但首次
new Monolog\Logger()就 fatal error，因为类文件里用了仅 PHP 8.2+ 支持的语法 - CI 流水线里加了它，等于把环境校验从构建阶段移到运行时，失去提前拦截能力
哪些参数会让 composer install 实质上“改环境”？
这些看似辅助的选项，一旦用错位置或时机，就会破坏锁定语义：
-
--optimize-autoloader本身不改依赖，但会重写vendor/composer/autoload_classmap.php；如果项目里有动态require或测试类混在 PSR-4 路径下，优化后直接Class not found -
--classmap-authoritative要求所有类都必须出现在 classmap 里，否则运行时报错——但它不会帮你检查，只会在启动那一刻失败 -
--no-plugins或--no-scripts会跳过post-install-cmd，而有些框架（如 Laravel）依赖它生成bootstrap/cache/config.php，漏掉就 500
真正危险的从来不是命令本身，而是你不确定它到底有没有老老实实读 lock 文件。每次部署前，先 ls -l composer.lock 和 git status --porcelain composer.lock 看一眼，比加十个参数都管用。
