答案是临时目录被安全策略拦截，需通过TMPDIR环境变量指定用户可控路径。应先用php -r "echo sys_get_temp_dir();"确认路径，再执行mkdir -p $HOME/.composer-tmp && chmod 700 $HOME/.composer-tmp，最后TMPDIR=$HOME/.composer-tmp composer install。
composer install卡在“failed to open stream”或“Permission denied”临时目录
这不是 Composer 本身的问题，而是它在解压包、生成 autoload 或写缓存时，试图往系统默认临时路径（如 /tmp）写文件，却被安全组、SELinux、容器挂载策略或云平台策略拦截。这类错误常见于阿里云 ECS、腾讯云 CVM 或 Kubernetes Pod 中——不是你没权限，是路径被策略“静默拒绝”。
先确认是否真卡在临时目录：composer install -vvv 看最后几行日志，如果出现类似 file_put_contents(/tmp/composer_archive_XXXXX): failed to open stream 或 mkdir(): Permission denied 且路径指向 /tmp 或 /var/tmp，就基本锁定问题。
- 检查当前临时目录：运行
php -r "echo sys_get_temp_dir();"，输出就是 Composer 实际用的路径 - 验证该路径是否可写：运行
touch $(php -r "echo sys_get_temp_dir();")/test && rm $(php -r "echo sys_get_temp_dir();")/test；失败则说明被策略阻断 - 云平台安全组通常不拦文件写入，但某些企业版镜像或自定义 OS 模板会启用 SELinux 或 AppArmor，默认禁止 PHP 进程往
/tmp写执行类文件（.phar 解包时触发）
如何绕过 /tmp 权限限制，指定用户可控的临时目录
别改系统 /tmp 权限，也别开 SELinux 宽松模式——直接让 Composer 用你有完全控制权的目录做临时中转。关键是覆盖 PHP 的 sys_get_temp_dir() 返回值，而不是只改 Composer 配置。
最稳妥的做法是在运行命令前临时设置环境变量：TMPDIR=$HOME/.composer-tmp composer install。这个变量优先级高于 PHP 默认，Composer 会自动识别并使用它。
- 先创建并授权：
mkdir -p $HOME/.composer-tmp && chmod 700 $HOME/.composer-tmp - 如果项目在 CI/CD（如 GitHub Actions），在 job 步骤开头加：
export TMPDIR=$(pwd)/.tmp && mkdir -p $TMPDIR - 注意：不要设成
/tmp的子目录（如/tmp/myproject），策略仍会生效；必须是用户主目录下全新路径 - 某些旧版 PHP（TMPDIR，此时需改 PHP 配置：
php -d sys_temp_dir="$HOME/.composer-tmp" composer install
Docker 容器里 vendor 写入失败，其实是挂载卷权限错位
报错里带 Permission denied 且路径指向 vendor/，但 ls -ld vendor/ 显示属主是你，这大概率是 Docker volume 挂载时 uid 不匹配。宿主机用户 uid 是 1001，容器内运行用户 uid 是 1000，哪怕目录归属看起来对，Linux 的 VFS 层仍会拒绝写入。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
典型现象：本地 composer install 成功，进容器跑就失败；或者 docker run --rm -v $(pwd):/app php:8.2-cli composer install 报错。
- 查宿主机用户 uid：
id -u；查容器内默认用户 uid：docker run --rm php:8.2-cli id -u - 启动容器时显式指定 uid：
docker run --rm -u $(id -u) -v $(pwd):/app php:8.2-cli composer install - 更彻底的解法：Dockerfile 里提前建好用户并设为非 root：
RUN useradd -u 1001 app && chown -R app:app /app，然后USER app - 别用
--privileged或cap-add=ALL，这等于关掉容器隔离，生产环境严禁
阿里云函数计算 FC 或 Serverless 环境下无法写 vendor
这类环境根本就没有持久化 vendor/ 目录的权限，所有写操作只能发生在 /tmp（且大小受限），而 Composer 默认行为是硬写到项目根目录。强行跑 composer install 必然失败。
正确做法是“构建时安装，运行时只加载”：在本地或 CI 构建镜像阶段完成 composer install --no-dev --optimize-autoloader，把 vendor/ 打包进部署包；函数代码里不再调用 composer install。
- 阿里云 FC 控制台上传 ZIP 包前，确保
vendor/已存在且完整，composer.lock和autoload.php都在 - 如果用 Terraform 或 s.yaml 部署，把
composer install放进build阶段，而非runtime阶段 - Serverless 场景下，
COMPOSER_HOME和cache-dir全部失效——因为/tmp重启即丢，别指望缓存能复用 - 验证方式：函数入口文件里加
var_dump(is_dir(__DIR__ . '/vendor'));，返回true才算真正就绪
临时目录权限问题最难 debug 的地方在于：它不报明确的“access denied”，而是表现为卡住、超时或静默失败。盯住 -vvv 日志里第一个 file_put_contents 或 mkdir 调用的目标路径，比猜配置更可靠。
