直接结论：Swap分区不能替代内存限制，必须配对使用；缓存限制本身不省内存，清理缓存却能显著降低解析阶段内存驻留。Swap只缓解物理内存耗尽，不解决Resolving dependencies阶段纯内存计算导致的OOM；composer clear-cache可清除废弃元数据，减少加载时冗余对象驻留，实测立竿见影。
直接结论：Swap 分区不能替代内存限制，但必须配对使用；缓存限制本身不省内存，清理缓存却能显著降低解析阶段的内存驻留。
为什么 swapfile 启用后 composer 还是被 kill
Swap 只缓解「物理内存耗尽」，不解决 Composer 在 Resolving dependencies 阶段的内存峰值问题。这个阶段 PHP 把整个依赖图、所有包的 autoload 映射、锁文件元数据全塞进数组——它不走磁盘缓存，纯内存计算，800MB+ 峰值在 512MB VPS 上会立刻触发 OOM killer，哪怕 Swap 已启用。
常见误操作：
- 只运行
sudo swapon /swapfile就以为万事大吉 - Swap 大小设成 512M，但 Composer 单次 peak > 1GB，Swap 不够用
- 没确认
swapon --show输出中TYPE是file且SIZE正确（常因fallocate失败导致实际为 0）
建议：至少创建 1G Swap 文件，并在 /etc/fstab 中添加持久化条目，避免重启失效。
COMPOSER_CACHE_DIR 设置无效的真正原因
COMPOSER_CACHE_DIR 环境变量只控制缓存写入路径，不减少内存占用；但它若指向 NFS、低速 HDD 或权限错误目录，会导致元数据读写卡顿，间接拉长高内存阶段的持续时间，增加 OOM 概率。
更关键的是：Composer 优先级顺序是「命令行参数 > 全局 config > 环境变量 > 默认路径」。很多人设了环境变量却没生效，是因为全局 config 里已用 composer config --global cache-dir 写死了旧路径。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
验证和修复步骤：
- 查当前生效路径：
composer config --global --list | grep cache-dir - 清冲突配置：
composer config --global --unset cache-dir - 临时测试：
COMPOSER_CACHE_DIR=/tmp/composer-cache composer install --dry-run，再检查/tmp/composer-cache是否有新文件生成 - 确保目标路径可写，且挂载在 SSD 或本地磁盘上（
/mnt/ssd/composer-cache更稳）
清理缓存比调参数更能立竿见影
composer clear-cache 不只是腾磁盘空间。旧缓存中可能含大量已废弃包的 ZIP 元数据、过期的 composer.json 解析结果，这些会在 Loading repositories 阶段被反复加载进内存，造成碎片和冗余对象驻留。
尤其当项目长期未更新、或曾切换过镜像源（比如从 packagist.org 切到阿里云），缓存里混杂着不同来源的元数据，Composer 会尝试合并、校验、去重——这一步纯 CPU + 内存密集，极易崩。
实操建议：
- 每次
composer install前先跑一次composer clear-cache - 如果用 Docker，把
COMPOSER_CACHE_DIR挂载为 tmpfs（内存盘），避免磁盘 I/O 拖慢解析 - 别信
--no-cache参数——它只跳过 HTTP 缓存，不影响本地磁盘缓存逻辑
真正容易被忽略的点：Swap 和缓存路径都是“基础设施层”动作，它们本身不改变 Composer 的行为逻辑；而一旦漏掉 --no-dev 或 --no-autoloader 这类流程砍断操作，前面所有配置都白搭——因为内存峰值压根没降下来。
