cache-files-ttl 控制 zip/tar 包复用，而非元数据刷新；它仅决定 ~/.composer/cache/files/ 下归档文件是否直接解压，过期才重新下载，但不影响 repo/ 目录下 packages.json 的缓存行为。
cache-files-ttl 控制的是 ZIP 包复用，不是元数据刷新
很多人以为 cache-files-ttl 是“缓存整体有效期”，其实它只管 ~/.composer/cache/files/ 下的 .zip 和 .tar 文件是否还能直接解压复用。只要这个时间没过（默认 15 天），Composer 就跳过下载，哪怕远程包已更新——这和“镜像穿透”无关，但常被误认为是穿透表现。
-
cache-files-ttl过期后，Composer 才会重新下载 dist 包，但依然可能读旧packages.json（元数据缓存）导致装错版本 - 元数据缓存（
repo/目录下）走的是硬编码 15 分钟不过期逻辑，不受cache-files-ttl影响 - 真正触发“穿透到源站”的不是缓存过期，而是本地缓存缺失 + 镜像不可用 + 无 fallback 配置
镜像不可用时，Composer 不会自动 fallback
Composer 没有内置重试或备用源机制。当你配置了 https://mirrors.aliyun.com/composer/，它就只连这个地址；一旦返回 404、502 或证书过期，就会报错退出，不会尝试清华源或官方源——这不是缓存过期问题，是配置层面的单点依赖。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 项目级配置（
composer.json中"repositories"）会覆盖全局镜像，且不继承 fallback 行为 -
composer config -g repos.packagist.url设置的只是单一 URL，不是源列表 - 要实现容灾，必须显式声明多个仓库并控制优先级，例如用
composer config -g repos.packagist.type composer+repos.packagist.url，再配合security.signature true
权限错配才是最常被当成“缓存穿透”的真凶
报错 file_put_contents(.../cache/repo/...): Permission denied 看起来像缓存层失效，实际是 ~/.composer 目录属主为 root，普通用户根本无法写入任何缓存文件——所有后续操作都会卡在第一步，连“是否过期”都无从判断。
- 运行
ls -ld ~/.composer，输出中第一列应为drwx------，第二三列必须是当前用户名，而非root - 修复必须一步到位：
sudo chown -R $USER:$USER ~/.composer→chmod 700 ~/.composer→chmod 600 ~/.composer/auth.json - 单独改
auth.json权限没用，因为父目录不可进入，整个缓存链就断了
手动清理缓存 ≠ 解决穿透，反而可能加剧问题
composer clear-cache 只删磁盘文件，不解决镜像不可达、权限错误或配置覆盖。更危险的是，它会清掉已验证的 ZIP 包，导致下次 install 必须重下，而如果此时镜像正不可用，就会彻底失败。
- 元数据缓存（
packages.json）不会被clear-cache清除，需用composer update --refresh（≥2.5）或手动删cache/repo/对应子目录 - CI 环境中应缓存
~/.composer/cache整个目录，而不是每次清空再重建 - 生产部署前，优先检查
composer diagnose输出中的secure-http和signature verification是否均为 OK，比盲目清缓存更重要
