vendor/目录创建失败根本原因是项目放错位置，必须移至~/myapp等可写用户目录再执行composer install；若属主为root则需删除vendor和composer.lock后以当前用户重装。
vendor/目录创建失败，大概率是项目放错了位置
在共享主机或无 root 权限环境里，composer install 报 mkdir(): Permission denied 或 file_put_contents(./vendor/autoload.php): Failed to open stream: Permission denied，根本不是 Composer 不能用，而是你把项目根目录放在了 Web 可访问路径下（比如 ~/public_html/myproject/）。这类目录通常被主机策略禁止 PHP 写入，尤其是自动生成 vendor/ 时。
必须把代码移到用户主目录下的纯可写子目录再执行安装，例如：
mkdir -p ~/myapp/myprojectcp -r ~/public_html/myproject/* ~/myapp/myproject/cd ~/myapp/myproject && composer install --no-dev --optimize-autoloader --no-interaction
装完后，通过 Web 服务器 alias、符号链接或 .htaccess 重写，把请求指向 ~/myapp/myproject/public/，而不是直接暴露 ~/public_html/。
vendor/属主是root，普通用户再运行就卡住
错误信息里出现 file_put_contents(/path/to/vendor/autoload.php)，说明问题就在 vendor/ 目录本身。常见原因是之前误用 sudo composer install，导致整个 vendor/ 树属主变成 root，后续普通用户无法修改或更新。
别试 chmod -R 755 vendor/ —— 新建文件仍受 umask 控制，且可能破坏软链结构。安全做法是：
- 删掉整个
vendor/和composer.lock：rm -rf vendor composer.lock - 确认当前用户对项目根目录有写权：
touch ./test-perm && rm ./test-perm，失败则chmod u+w . - 重新跑
composer install（不加sudo）
PHP CLI 缺扩展，连 vendor/ 都没机会创建就退出
在 CentOS 等最小化系统上，composer install 可能根本走不到创建 vendor/ 这步，而是直接报错退出，比如 ext-zip missing、ext-mbstring is required。这是因为 Composer 2.x 启动时就检查核心扩展，缺一个就终止。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
先确认 PHP CLI 环境达标：
-
php -m | grep -E "zip|mbstring|fileinfo|openssl|curl"—— 输出里必须全有 -
php --ini查配置路径，确认对应.ini文件没禁用关键函数（如disable_functions = system,exec） -
php -r "echo file_get_contents('https://packagist.org/');"验证 HTTPS 请求是否通
如果缺扩展，得用包管理器装，比如 CentOS 上：sudo yum install php-zip php-mbstring php-fileinfo。
composer.lock 不存在，install 命令直接被拦截
新项目或刚 clone 下来就跑 composer install，报 No composer.lock file present 或 Command "install" is not defined，这不是网络或权限问题，而是 Composer 的硬性规则：没有 composer.lock，install 就不工作。
正确流程只有两个选择：
- 如果是全新项目，先跑
composer update（不是install），生成composer.lock - 如果是团队项目，确认
composer.lock已提交到 Git —— 它必须和composer.json一起存在
误删后只重跑 install 没用；composer update --lock 也无效，因为没锁文件就无法做“锁版本更新”。最稳妥的是删干净再重来。
最容易被忽略的点：报错路径未必就是你要修的地方。比如 Permission denied 看似在 vendor/，实际可能是 ~/.composer/cache/ 或 opcache 缓存目录不可写引发的连锁失败。先看错误信息里明确写出的路径，再顺藤摸瓜查归属和父目录权限。
