云函数或无服务器环境运行时执行composer install必然失败，因平台存在三重硬限制：文件系统只读、无PHP CLI、无网络连接；必须在CI构建阶段用一致环境镜像预装依赖，并严格使用--no-dev --optimize-autoloader --classmap-authoritative等参数确保autoload_static.php生成。
不能在云函数或无服务器环境里运行 composer install——它必然失败，且错误常被静默吞掉，不是配置问题，是平台硬限制。
为什么运行时执行 composer install 必然失败
云函数（如 AWS Lambda、阿里云函数计算）和只读容器的运行时有三重不可绕过限制：
-
file_put_contents()报Permission denied：不是权限没设对，是/var/task或/opt目录内核级只读挂载 -
Could not open input file: composer.phar：运行时根本没装 PHP CLI，也找不到可执行的composer二进制 - 即使强行塞入
composer.phar，也会卡在下载阶段：curl/git 被禁用、私有源 401、zip 解压失败（缺ext-zip） -
post-install-cmd如php artisan config:cache因缺失APP_KEY或 DB 连接而退出码为 1，但日志只显示 “execution completed”
必须在 CI 构建阶段预装依赖并打包 vendor
所有依赖必须提前打进部署包或镜像，运行时只做轻量初始化。关键动作包括：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 使用与目标运行时完全一致的构建镜像，例如：
public.ecr.aws/sam/build-php8.2（AWS）、registry.cn-hangzhou.aliyuncs.com/aliyunfc/runtime-php82:build（阿里云） - 执行命令必须带全参数：
composer install --no-dev --optimize-autoloader --classmap-authoritative --prefer-dist - 紧接执行：
&& composer dump-autoload --optimize --classmap-authoritative，否则vendor/composer/autoload_static.php不生成，Lambda 启动时报Class not found - 显式复制缓存目录：
cp -r /root/.composer/cache ./composer-cache，上传至对象存储或作为构建缓存复用，避免每次重建都重下几十 MB 包 - 若项目含
post-install-cmd，CI 中需注入必要变量（如APP_ENV=production），并用set -e捕获非零退出码
容器构建中常见 vendor 层失效原因
很多人以为加了 --prefer-dist 就能提速，结果每次构建都重跑 composer install，根源在于 Docker 缓存未命中：
- Dockerfile 中
COPY . .放在RUN composer install之前，导致每次代码变更都使 vendor 缓存失效 - 正确顺序应是：
COPY composer.json composer.lock ./→RUN composer install --no-dev ...→COPY . . - 若
composer.lock未提交到 Git，或被.dockerignore错误排除，构建时会 fallback 到composer update行为，结果不可控 - 构建镜像用了不同 PHP 版本或扩展（如缺
ext-gd），会导致锁文件中某些包无法安装，但错误可能被--no-interaction吞掉
如何判断一个 post-install-cmd 是否真危险
别只看脚本字符串是否含 exec，很多恶意逻辑藏得更深：
- 检查是否调用
file_put_contents(__DIR__.'/../public/shell.php', ...)——写 Web 可访问路径是常见攻击面 - 搜索
base64_decode(、gzinflate(、str_rot13(，这些常用于隐藏 payload - 运行
composer validate --strict，它会警告含curl、wget、http://的脚本命令 - 对疑似命令加
echo测试真实展开：echo "php -r 'echo getenv(\"PATH\");'"，观察是否泄露敏感环境变量
真正难处理的不是“怎么装”，而是“怎么确保装出来的 vendor 在冷启动瞬间就能被 autoload_static.php 正确加载”——路径映射错位、类名大小写不一致、PSR-4 命名空间漏配，都会让函数第一次执行就报错，且没有堆栈提示。
