Composer不生成需备份的临时文件，其运行时创建的临时zip文件存于系统临时目录（如/tmp），解压后应自动清理；真正需Git提交的仅有composer.json和composer.lock。

Composer 本身不生成需要“备份”的临时文件——那些文件是运行时创建、用完即弃的，备份它们既无意义，还可能干扰后续执行。

composer install/update 产生的临时文件在哪

Composer 下载包时会把 zip 包解压前暂存在 sys_get_temp_dir() 返回的路径里（Linux/macOS 通常是 /tmp，Windows 是 %APPDATA%\Local\Temp），文件名类似 composer_XXXXXX.zip。这些文件在解压完成后本该自动清理，但偶尔因中断或权限问题残留。

• 它们不是项目资产，不参与版本控制，也不影响 vendor 重建
• 备份 /tmp/composer_*.zip 没用：下次 composer install 会重新下载，旧 zip 可能已失效或不兼容新 lock 文件
• 真要“保留下载物”，应该用 ~/.composer/cache/ 目录——那是 Composer 自己维护的持久化包缓存，不是临时文件

误把 vendor/composer/installed.json 当作临时文件来备份

有人看到 vendor/composer/installed.json 或 vendor/autoload.php 频繁变化，就以为是“临时产物”想单独备份。其实这些是 Composer 正常工作输出，依赖 composer.lock 和当前 vendor/ 状态动态生成。

Academic Composer Upload

辅助学术写作，包括查找资料、生成大纲、引用扩写及润色风格，同时确保引用规范。

下载

• 删掉 installed.json 后运行 composer install 会自动重建，无需备份
• 把它从 Git 忽略列表里移出反而容易引发冲突（尤其多人协作时）
• 真正该进 Git 的只有 composer.json 和 composer.lock

如果你真需要“保留某次安装的完整快照”

那不是备份临时文件，而是备份整个可复现环境：

• composer.lock 必须在 Git 中提交——它是依赖版本的唯一事实来源
• 如需离线恢复，打包 vendor/ 目录 + composer.lock 即可（注意不要含 vendor/bin/ 的软链接，跨系统可能失效）
• 全局缓存 ~/.composer/cache/ 可以 rsync 备份，但它属于开发机本地优化，不随项目迁移
• 别碰 /tmp 下的 composer_*.zip：清空它用 find /tmp -name 'composer_*' -mmin +60 -delete 更合理

临时文件的存在本身就是设计的一部分，强行备份只会模糊“什么该持久化、什么该重建”的边界。盯住 composer.lock，管好 vendor/ 的生命周期，比打捞 /tmp 里的碎片可靠得多。