生产环境唯一安全命令是composer install，因其严格按composer.lock精确安装版本、哈希与来源，不读取composer.json约束；而composer update会重写lock文件、引入不确定性，必须禁用。
生产环境依赖必须锁定版本且禁止自动更新，否则部署可能因依赖漂移失败。
为什么 composer install 是生产环境唯一安全命令
开发时用 composer update 会重写 composer.lock，拉取最新兼容版本——这在生产环境等于主动引入不确定性。而 composer install 严格按 composer.lock 中记录的精确版本、哈希和来源安装，不读 composer.json 的版本约束。
- CI/CD 流水线中，必须确保
composer install --no-dev --optimize-autoloader --classmap-authoritative是唯一执行的命令 -
--no-dev排除require-dev里的包（如 PHPUnit、phpstan），避免生产环境加载测试相关代码 -
--optimize-autoloader生成扁平类映射，减少文件系统查找开销 -
--classmap-authoritative告诉 autoloader “所有类都在 classmap 里”，跳过 PSR-4 文件扫描，提升性能且更可控
composer.lock 必须提交到 Git，且禁止忽略
很多人误以为 composer.lock 是“临时文件”而加进 .gitignore，这是生产事故高发原因。它不是缓存，而是依赖快照的权威声明。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 每次
composer update后，composer.lock必须git add并随代码一起提交 - 部署脚本若发现本地没有
composer.lock，应直接报错退出，而不是 fallback 到composer install自动创建 - 私有包仓库（如 Satis 或 Private Packagist）的认证凭据不能硬编码在
composer.json；应通过auth.json管理，并确保该文件不在 Git 中，但部署时由 CI 注入
如何防止意外执行 composer update 或写入操作
生产服务器文件系统权限和 Composer 配置双管齐下，才能堵住人为或脚本误操作。
- 部署后立即运行
chmod -w composer.json composer.lock（只读），让后续composer update直接失败 - 在项目根目录放
composer.json的只读副本（如composer.json.readonly），CI 脚本校验主文件是否被修改 - 全局配置禁用交互式操作：
composer config --global discard-changes true+composer config --global secure-http true，降低非预期行为风险 - 若使用容器部署，Dockerfile 中应明确指定
RUN chown -R www-data:www-data /var/www/html && chmod -R u-w /var/www/html/composer.*
最常被忽略的一点：即使锁文件完整、命令正确，如果 PHP 运行时启用了 allow_url_fopen 且未限制 composer install 的网络访问，某些插件仍可能绕过锁文件远程拉取元数据。生产环境应禁用 allow_url_fopen 或通过防火墙策略封锁 Packagist 域名以外的所有出站 HTTP 请求。
