“command not found”根本原因是path未包含composer.bat路径，需将c:\programdata\composersetup\bin手动加入系统环境变量path，关闭所有终端后新开验证where composer是否返回该路径。
“command not found”：根本没找到composer.bat或php.exe
Windows上跑composer --version报“不是内部或外部命令”，90%不是没装，而是PATH没加对。系统压根没看到composer.bat文件。
先确认composer.bat真实位置：在文件资源管理器里输入%PROGRAMDATA%\ComposerSetup\bin（需开启“显示隐藏的项目”），看里面有没有composer.bat和composer.phar。有的话，就把这个完整路径——只到bin目录，不带文件名——粘贴进「系统变量」→Path→「新建」，例如：C:\ProgramData\ComposerSetup\bin。
- 别错加成
php.exe所在路径（比如C:\php） - 末尾别多加反斜杠或空格（
C:\ProgramData\ComposerSetup\bin\会失效） - 改完必须关掉所有已打开的CMD/PowerShell/VS Code终端，再新开一个
- 验证：运行
echo %PATH%看输出里有没有你刚加的路径；再跑where composer，应返回类似C:\ProgramData\ComposerSetup\bin\composer.bat
“file could not be downloaded”：国内直连Packagist基本不可靠
卡在Loading composer repositories或Downloading，日志里没出现镜像域名？说明根本没走你配的镜像，还在死磕packagist.org。
立刻切阿里云镜像：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/（注意：结尾必须有/，type必须是composer，且一定要带-g）。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 切完必须执行
composer clear-cache，否则缓存里还存着旧失败记录 - Windows用户还得手动删
%LOCALAPPDATA%\Composer\cache - 删掉
vendor/和composer.lock——composer.lock里硬编码了旧源地址，不删它，Composer就一直重试失败路径 - 验证镜像是否真可用：
curl -I https://mirrors.aliyun.com/composer/packages.json必须返回HTTP/2 200；若返回HTML页面（如人机验证），说明该镜像不适合自动化场景
“Permission denied”：不是权限不够，是所有权归了root
报错里明确写了路径，比如file_put_contents(/home/alex/myapp/vendor/autoload.php): Failed to open stream: Permission denied，那就直接盯住vendor/这个目录。
运行这三行查归属：ls -ld vendor/、ls -ld composer.lock、ls -ld $(composer config --global cache-dir)。只要任意一行第一列显示root，就是所有权错配，不是rwx权限问题。
- 修复项目内目录：
sudo chown -R $USER:$USER vendor/ composer.lock - 修复全局缓存：
sudo chown -R $USER:$USER $(composer config --global cache-dir) - 整个
~/.composer都属root？直接重置：sudo chown -R $USER:$USER ~/.composer - 别用
chmod -R 777——它会让vendor/bin/phpunit这类可执行文件被CI工具或安全扫描器拒收，后续composer update可能只失败一半
“Your requirements could not be resolved”：依赖冲突，不是网络或权限问题
这个错误说明Composer已经拿到全部元数据，但在本地求解时找不到一组满足全部约束的版本组合。它不怪镜像、不怪网速，只怪约束之间打架了。
运行composer why-not php:8.3（把8.3换成你目标PHP版本），直接看到哪个包在拦路。比如输出laravel/framework v10.42.0 requires php ^8.1，但你项目里还有个包锁死了php: ^7.4。
- 检查
composer.json里有没有写死版本号，例如"monolog/monolog": "2.9.0"，而新引入的包要求^3.0 - 确认PHP CLI版本和扩展真实可用：
php -v和php -m | grep -E "mbstring|openssl|curl|json"，别只信phpinfo()页面——Web和CLI可能加载不同php.ini -
composer install --ignore-platform-reqs只是临时绕过，不会修复问题，上线前必须让代码真兼容目标环境
sudo composer install可能让vendor/下混进个别root所有子目录，ls -la vendor/就能发现。这时候别硬修，直接rm -rf vendor/再重装更省事——前提是确认当前用户对项目目录有完全控制权。
