composer self-update 必须手动触发，不自动运行；需满足网络、php兼容、文件可写前提，cron易因时间偏差、path混乱、windows锁定或国内网络失败；仅在修复bug、启用新功能、ci锁定版本或确认过旧时才执行，并须验证版本、路径及源配置。
composer self-update 不是“该什么时候执行”，而是“必须在明确意图下手动触发”——它从不自动运行，也没有内置定时机制。
为什么不能设 crontab 自动跑 self-update
self-update 本身是原子化替换 composer.phar 的单次操作，不涉及项目依赖或锁文件，但它仍需满足三个前提：网络可达 GitHub Releases、PHP 版本兼容、本地文件可写。cron 环境下常因以下原因静默失败：
- 系统时间偏差导致 GPG 签名校验失败（
Signature mismatch） - PATH 中存在多个
composer，which composer返回的路径与实际更新目标不一致 - Windows 下因文件锁定直接报
Access is denied，且 cron 无法捕获 stderr - 国内服务器默认走 GitHub，未配置镜像源时超时无提示
哪些场景下你才该手动执行 self-update
不是“定期维护”，而是“有明确升级动机”时才运行：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 发现已知 bug 被修复（比如某次
composer install在 PHP 8.3 下崩溃，而 v2.7.7 已修复） - 需要使用新功能（如 v3 的
composer require --dev行为变更、插件 API 升级） - CI 环境中需锁定版本保证可重现性：
composer self-update 2.7.7，而非盲目 latest - 确认当前版本过旧（如还在用 v2.2.x），且已满足 PHP ≥ 8.0 要求
执行前必须验证的三件事
跳过任一检查，self-update 就可能让你的环境进入“看似成功、实则失效”状态：
- 运行
composer --version，确认输出末尾含 commit hash 和日期，不只看版本号 - 运行
which composer和ls -l $(which composer)，判断是否为 PHAR 文件或软链接，避免更新了 wrapper 却没动真实二进制 - 若用国内镜像源，先切回官方源：
composer config -g repo.packagist composer https://packagist.org，否则可能被缓存误导显示 “Up to date”
v2 → v3 这类主版本跃迁最容易出问题
它不是升级，是切换通道。v3 改变了 lock 文件结构、移除了 content-hash、要求插件重适配。即使你执行了 composer self-update --3，后续首次 composer install 仍可能报错 The lock file does not contain require-dev information —— 此时必须删掉 composer.lock 重建，没有绕过办法。
