Composer 本身不提供内置自动更新功能，需通过 cron 定时执行 composer update --no-interaction --dry-run 仅更新 require-dev 工具包并记录日志；生产环境禁用自动更新，应改用 composer outdated 辅助人工判断与测试后手动更新。
composer 本身不提供内置的自动更新依赖功能，也没有配置文件能“开启定时更新”。所谓“自动更新依赖”，本质是靠外部调度 + 手动命令组合实现的，不是 Composer 自己在后台偷偷拉包。
怎么让依赖每周自动更新一次（Linux/macOS）
靠系统级定时任务（cron）驱动 composer update，但必须加约束，否则会破坏稳定性。
- 只更新
require-dev中的工具类包（如phpunit/phpunit、friendsofphp/php-cs-fixer），避免影响运行时逻辑 - 务必加上
--no-interaction和--dry-run先试跑，确认无冲突再删掉--dry-run - 输出重定向到日志，方便排查失败原因：
composer update --no-interaction --dry-run > /var/log/composer-weekly.log 2>&1 - 不要用
composer update全量更新——它会重算整个依赖图，极易引入 BC Break
为什么不能对生产环境开“自动更新”
因为 composer update 的行为不可预测：它会根据 composer.json 中的版本约束（比如 ^2.8）去 Packagist 拉最新匹配版，而这个“最新”可能包含非预期的次要更新甚至补丁更新，触发以下问题：
-
monolog/monolog从2.9.1升到2.10.0，但新版本悄悄改了Logger::error()的参数顺序 -
guzzlehttp/guzzle更新后要求 PHP 8.1+，而你的服务器还是 8.0 -
composer.lock被重写，CI 构建时拉不到旧版 dist 包，导致部署卡住
真正安全的做法是：人工触发 + PR + 测试 + 合并，而不是机器半夜自己跑。
想省事？用 composer outdated 替代自动更新
它不改任何东西，只告诉你哪些包有新版本可选，把决策权留给人：
-
composer outdated：列出所有可更新的包（含当前/建议版本） -
composer outdated --direct：只看composer.json里直接声明的包，忽略嵌套依赖 -
composer outdated --minor-only：只显示次要版本更新（如3.2 → 3.3），跳过3.3 → 4.0这种大变更 - 配合 CI 脚本，在 PR 构建阶段跑一次，失败就提醒开发者手动 review，比盲目自动更可控
自动更新依赖听起来省心，实际最危险的环节往往藏在“版本约束没写死”和“没跑兼容性测试”这两步里。别信“一键全自动”，信 outdated + 人工判断 + 锁定 composer.lock。
