composer镜像同步系统不管理数据生命周期和冷热分级，需用户主动设计；同步延迟决定数据新鲜度，阿里云1–3分钟、腾讯/华为云5–10分钟、清华源小众包超15分钟；本地缓存中vcs/目录易耗尽inode，/tmp下临时文件需单独清理。
Composer 镜像同步系统本身不管理数据生命周期，也不支持冷热分级存储——它只是个只读 HTTP 服务端，所有“生命周期”和“冷热”逻辑必须由你主动设计并落地。
镜像站同步延迟才是实际的数据“新鲜度”边界
阿里云镜像首波同步通常 1–3 分钟，腾讯云/华为云常见 5–10 分钟，清华源对小众包可能延迟超 15 分钟。这意味着：
- 你执行
composer update --refresh后仍装不到新版，大概率不是 Composer 没刷新，而是镜像站压根还没 pull 到那个package-name.json - 直接访问
https://mirrors.aliyun.com/composer/p/vendor/package-name.json查版本是否存在，比反复重试更可靠 - 没有“同步频率配置项”，
repos.packagist的 URL 改了也不会自动触发同步——那是镜像站后台 cron 或 webhook 的事
本地 Composer 缓存目录天然具备冷热特征，但需手动干预
~/.composer/cache/ 下三个子目录行为差异极大：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
files/：ZIP 包缓存，体积大（单个 Laravel dist 可超 80 MB），受cache-files-ttl和cache-max-size控制，可被composer clear-cache清理 -
vcs/：Git 裸仓库缓存，单个 300–800 MB、含上万小文件，完全不参与任何自动 GC，是 inode 耗尽主因；必须手动rm -rf ~/.composer/cache/vcs/并永久禁用：composer config --global cache.vcs false -
repo/：元数据缓存，硬编码 15 分钟 TTL，不可调；--refresh强制跳过它重拉，但不会改变其缓存策略
真正可行的冷热隔离方案只有两种落地路径
别指望 Composer 或镜像站帮你分层——你得自己划线、挂载、调度：
-
物理路径隔离：把
cache-dir指向 SSD 分区（热），再用COMPOSER_CACHE_DIR环境变量在 CI/CD 中临时切到 HDD 或 NFS（冷），靠脚本控制生命周期 -
用途隔离：开发机保留完整缓存（含 vcs），CI 构建节点禁用 vcs + 设定短 TTL（如
604800秒）+ 每次构建后rm -rf $COMPOSER_CACHE_DIR/files/，只留元数据 - 注意：
sys_get_temp_dir()下的composer_*.zip和php*.phar不在 cache 目录里，却常吃光/tmp空间和 inode，必须单独清理
冷热不是配置开关，是目录归属、清理节奏和挂载位置的组合决策；最常被忽略的是 vcs/ 目录的静默膨胀和 /tmp 下临时文件的失控增长——它们不报错，但会让你的构建机某天突然卡死在 No space left on device。
