Composer本身不生成临时文件，其输出仅限vendor/autoload.php、vendor/composer/autoload_*.php、composer.lock和vendor/composer/installed.json等确定性路径文件；其他如tmp_、cache-、.json、.js等均为Laravel Mix、Vite、Xdebug等工具产物。
Composer 本身不生成“临时文件”用于运行时缓存或中间产物——它只在 vendor/ 写包、在 composer.lock 记版本、在 vendor/autoload.php 生成自动加载逻辑。你看到的所谓“临时文件”，99% 是其他工具（如 PHP OPcache、Xdebug、Laravel Mix、Vite、或某些调试扩展）写入的，被误认为是 Composer 的产物。
怎么判断一个文件是不是 Composer 生成的
Composer 只会在以下位置写文件，且命名有明确规则：
-
vendor/autoload.php—— 固定名称，每次dump-autoload或 install/update 都会重写 -
vendor/composer/autoload_*.php（如autoload_static.php、autoload_classmap.php）—— 前缀固定为autoload_，后缀由生成策略决定 -
composer.lock—— 固定名，JSON 格式，含哈希与完整依赖树 -
vendor/composer/installed.json—— 每次 install/update 后更新，记录已安装包元数据
凡是以 tmp_、cache-、frame-、effect-、lottie-、.log、.bin、.dat 等开头或结尾的文件，都不属于 Composer。
为什么 composer install 后会出现奇怪的 JSON/JS 文件
常见真实来源：
- Laravel Debugbar 或 Ray 在
storage/debugbar/或storage/ray/下写入调试快照（含时间戳和随机 ID） - Vite 或 Webpack 插件把 AE 动画导出为
public/js/lottie-*.json，路径可能在public/或dist/ - 某些 UI 组件库（如 Ant Design Pro 的 mock 数据层）在构建时生成
mock/*.js，名字带 hash 或 timestamp - Xdebug 的 trace 文件（
xdebug.*.xt）或 OPcache 的 dump（opcache-*.bin）被误扫进项目目录
验证方法：执行 grep -r "lottie\|keyframe\|effect" --include="*.json" --include="*.js" .，看输出里是否指向某个具体包的 vendor 子目录或 build 脚本。
如何快速定位非 Composer 文件的真实来源
别猜，用三步锁定：
- 查 Git 提交：
git log -n 10 --oneline --name-only | grep -E "\.(json|js)$"，看最近谁提交了这类文件 - 查进程写入：
lsof +D ./ | grep -E "(json|js)"（Linux/macOS），或用 Process Monitor（Windows）过滤写操作 - 查构建配置：搜
webpack.mix.js、vite.config.js、laravel-mix、rollup.config.js里是否有copy、emitFile、writeFileSync等调用
Composer 不管文件内容、不解析 JSON、不渲染动画、不打光——它只做一件事：按 composer.json 把对的包放进 vendor/，并确保你能 new 出来。
真正要清理的不是“Composer 临时文件”，而是那些被错误归因的构建产物或调试残留。它们的名字看起来随机，是因为生成逻辑依赖时间戳、hash 或运行时状态——而 Composer 的所有输出，都严格遵循语义化命名和确定性路径。
