缓存目录不会被白名单覆盖，二者完全独立：cache-dir 控制文件复用路径，allow-plugins 仅授权插件执行权限；白名单不干预缓存配置，缓存路径失效与否取决于路径存在性、权限及 COMPOSER_CACHE_DIR 环境变量优先级。
缓存目录是否被白名单覆盖？
Composer 的缓存行为和白名单（config.allow-plugins）完全不重叠——前者管文件复用，后者只控制插件加载权限。即使你把 composer/installers 加进白名单，也不会影响 cache-dir 路径是否生效，反之亦然。
常见误解是：「我加了白名单，缓存就自动同步到指定目录」。错。缓存路径由 cache-dir 配置决定，白名单只是告诉 Composer 「允许哪些插件在 install/update 时运行」。
-
cache-dir必须写在composer.json的config下层，或通过composer config cache-dir /path/to/cache设置 -
allow-plugins是顶层字段，不能嵌套在config里，否则被忽略 - 白名单不校验路径合法性，但缓存路径若不可写，Composer 会静默 fallback 到系统默认位置（如
~/.composer/cache），且不报错
白名单插件能否修改缓存行为？
能，但仅限于插件自身逻辑。比如 hirak/prestissimo（已归档）曾通过并行下载减少缓存写入延迟；composer-normalize 完全不碰缓存。关键点在于：插件是否读写缓存，取决于它自己，不是白名单赋予的权限。
如果你依赖某个插件来「预热缓存」或「清理旧版本包」，得确认它是否真有对应命令或钩子，而不是指望白名单自动触发。
- 插件必须在
allow-plugins中显式声明才能执行，哪怕它只是调用file_put_contents()写缓存目录 - 插件无权绕过
cache-read-only: true—— 这个配置会直接让所有写缓存操作失败，插件也一样 - CI 环境中常设
COMPOSER_CACHE_DIR=/tmp/composer-cache，此时白名单插件仍可运行，但所有缓存操作都落在该路径下
缓存 TTL 和白名单插件的生命周期冲突吗？
不冲突，但容易误判。例如你设了 "cache-files-ttl": 86400（1天），又装了自动更新包信息的插件，第二天 composer update 仍可能拉新元数据——因为 cache-files-ttl 只管压缩包（.zip/.tar），不管 repo/ 下的 JSON 元数据缓存（它走的是 cache-repo-ttl，默认 15 分钟）。
白名单插件若依赖过期的元数据做判断（比如检查远程最新 tag），就会出错，但这和缓存 TTL 配置无关，而是插件没处理好元数据刷新时机。
-
cache-files-ttl控制files/子目录内归档文件的有效期 -
cache-repo-ttl控制repo/下各仓库packages.json的有效期（需手动配置，无默认值） - 插件无法修改这两个 TTL 值，只能读取；想强制刷新，得加
--no-cache或删对应子目录
容器化部署时白名单+缓存最简可靠配置
在 Docker 或 Kubernetes 中，缓存目录挂载和插件白名单必须分开验证，缺一不可。很多人只配了 VOLUME ["/root/.composer/cache"] 却忘了插件被默认禁用，结果脚本不执行、缓存不复用，还查不出原因。
最简可用组合：
- 基础镜像里提前运行
composer config --global allow-plugins."myorg/deploy-plugin" true，避免每次构建都交互确认 - Dockerfile 中用
ENV COMPOSER_CACHE_DIR=/composer/cache，再VOLUME ["/composer/cache"] - 不要在
composer.json里写allow-plugins—— 容器里项目是只读的，全局配置更可控 - 验证方式：
docker run -it myapp composer show --plugins应列出插件；ls -l /composer/cache/files | head -3应有近期文件
白名单不是开关，是授权；缓存不是魔法，是路径+权限+TTL 的组合。两者配合的前提，是各自先独立跑通。
