Composer缓存目录含files/（下载包）、repo/（元数据）、vcs/（Git裸仓库，300–800MB，默认不清）、installers/（极小），其中vcs/是磁盘与inode主要占用者，需手动清理或禁用cache-vcs。
Composer缓存目录里到底存了什么文件
Composer的~/.composer/cache（Linux/macOS）或%APPDATA%\Composer\Cache（Windows）不是黑盒，它由四个明确子目录组成，每类文件用途不同、清理策略也不同：
-
files/：存下载好的.zip或.tar.gz归档包，文件名含哈希（如monolog-monolog-1.27.0-zip-fea3b5.zip），按vendor-name/package-name-version-hash格式组织 -
repo/：存packages.json等元数据，是JSON文件，内容来自镜像源响应，不包含二进制数据 -
vcs/：存完整git clone副本（含.git目录），每个包占300–800 MB，但默认不被composer clear-cache清理 -
installers/：极小，存插件安装器缓存，基本可忽略
中文环境下无特殊编码处理——所有路径和文件名均使用UTF-8，但Composer本身不解析文件名语义，只靠SHA-256哈希校验完整性。你看到的中文包名（如yiisoft/yii2）只是路径组成部分，不影响存储逻辑。
为什么composer clear-cache不删vcs/目录
这不是疏漏，而是设计使然：vcs/目录用于--prefer-source安装场景，其内容是完整Git仓库，Composer认为“可能复用”，所以跳过清理。但实际中，除非你频繁切换分支或调试源码，否则99%的项目根本不会重用这些克隆。
- 执行
composer clear-cache后，vcs/仍存在，且下次composer install --prefer-source会直接复用，不重新克隆 - 但如果你只用
--prefer-dist（默认），vcs/完全闲置，纯属磁盘空间黑洞 - 安全清理命令：
rm -rf ~/.composer/cache/vcs/（Linux/macOS）或rd /s /q "%APPDATA%\Composer\Cache\vcs"（Windows） - CI或小磁盘机器建议永久禁用：
composer config --global cache-vcs false，后续所有Git包强制走--prefer-dist
注意：IDE（如PhpStorm）或杀毒软件可能锁住vcs/内文件，导致rm失败，需先关闭文件索引或实时扫描。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
cache-files-ttl和cache-files-maxsize怎么协同工作
这两个参数控制files/目录的生命周期，但行为完全不同，容易误判：
-
cache-files-ttl（默认15552000秒=6个月）：仅影响文件“最后访问时间”（atime），不是创建时间。Composer垃圾回收时，只删那些“6个月内没被任何composer install/update读取过”的zip包 -
cache-files-maxsize（默认300MiB）：按整个files/目录总大小触发LRU式清理——但注意，这是Composer模拟的LRU，实际按文件修改时间（mtime）排序，删最旧的直到低于阈值 - 二者不冲突：先按
maxsize触发清理，再按ttl做二次过滤；若maxsize设得过大（如"2G"），ttl可能长期不生效 - 配置示例：
{ "config": { "cache-files-ttl": 2592000, "cache-files-maxsize": "500MiB" } }
关键点：这两个参数对vcs/和repo/完全无效，它们有自己的清理逻辑（或干脆不清理）。
中文项目里哪些缓存行为最容易被忽略
中文环境本身不改变缓存机制，但本地化实践常引入隐性陷阱：
- 误信“镜像源自带缓存”：阿里云、腾讯云镜像只是HTTP代理，不存用户级包，
cache-dir才是唯一真实缓存位置 - 在Docker中只缓存
~/.composer/cache却每次清空vendor/：这等于只省下载时间，不解压+写入时间，实际提速有限 - 用
COMPOSER_HOME改配置路径，但没同步更新CI缓存key：比如COMPOSER_HOME=/tmp/composer，却仍用~/.composer/cache当cache key，导致缓存失效 - 开发机开Xdebug，生产构建却忘了关：Xdebug会让
composer install慢3–5倍，且composer config查不到这个影响因子
最隐蔽的问题是cache-dir路径权限：如果设为/mnt/ssd/composer-cache但PHP进程无写权限，Composer会静默 fallback 到默认路径，composer config --global cache-dir显示的值和实际写入位置不一致。
