关键是在部署前清理四类缓存：一、运行时缓存，用post-autoload-dump触发框架清理或手动删除storage/framework/cache等目录；二、构建缓存，前端资源加时间戳或哈希，响应头设no-cache；三、Nginx/CDN缓存，通过proxy_cache_bypass或API主动purge；四、模型级缓存，用core-cli cleanup --ttl 0s清理LLM缓存，并删.metadata_cache.bin后发SIGUSR2重载。
要让自动化部署脚本在真正执行前就清掉可能干扰新版本的缓存，关键不是“等部署完再清理”，而是把清理动作前置到依赖安装或服务重启之前，并覆盖所有可能残留旧数据的层级：运行时缓存、构建产物缓存、框架元数据缓存、CDN/反向代理缓存。以下四类操作需按顺序嵌入部署流程。
一、部署前强制刷新框架与运行时缓存
很多框架（如 Laravel、Symfony）的缓存文件会锁住旧配置或视图，若不清除，新代码可能读取过期的 compiled.php 或 cache/data/ 下的序列化数据。不能依赖 post-install-cmd，因其执行时机不可靠。
- 改用 post-autoload-dump 阶段触发清理，确保 autoload 已就绪：
"post-autoload-dump": ["@php artisan config:clear --no-interaction --env=production", "@php artisan cache:clear --no-interaction --env=production"] - 对非 Laravel 项目，直接在部署脚本开头执行：
rm -rf storage/framework/cache/* bootstrap/cache/* var/cache/prod/* - 若使用 Redis/Memcached，部署前执行：
redis-cli -n 0 FLUSHDB && memcached-tool 127.0.0.1:11211 flush
二、构建阶段注入唯一标识并禁用 HTML 缓存
前端资源被浏览器或 CDN 缓存，会导致用户加载旧 JS/CSS，即使后端已更新。必须从源头切断复用路径。
- 确保 index.html 响应头含：
Cache-Control: no-cache, no-store, must-revalidate - 所有静态资源引用带构建时间戳或哈希值，例如：
<script src="main.js?_v=202605281700"></script> - Vite/Webpack 构建时自动注入版本号，避免手写错误；CI 中可设：
BUILD_NUMBER=$(date -u +%Y%m%d%H%M)
三、Nginx / CDN 层缓存预失效
反向代理缓存不响应文件变更，需在部署指令发出的同时主动使其“过期”或绕过。
- 配置 Nginx proxy_cache_bypass，部署后立即发一次带参请求：
curl "https://site.com/?refresh=1" → 触发新内容回源并覆盖缓存键 - 若使用支持 purge 的 CDN（如 Cloudflare），在部署脚本末尾调用 API 清除对应路径：
curl -X POST "https://api.cloudflare.com/client/v4/zones/{zone_id}/purge_cache" \
-H "Authorization: Bearer ${API_TOKEN}" \
-H "Content-Type: application/json" \
-d '{"files":["https://site.com/app.js"]}'
四、模型与权重级缓存强制重载（AI 服务专用）
大模型服务（如 Core）中，/cache/llm/ 下的激活缓存、分片权重、.metadata_cache.bin 等若未清理，推理结果可能混入旧模型特征。
- 部署新模型前，运行：
core-cli cleanup --scope cache --ttl 0s --dry-run false
（--ttl 0s 表示无条件清理所有非锁定项） - 若修改了 config.json/tokenizer.json，手动删掉对应模型目录下的：
.metadata_cache.bin - 发送重载信号，使服务重新解析元数据：
kill -SIGUSR2 $(pgrep -f "core-server")
