Composer命令报“不是内部或外部命令”是因系统还原清空PATH，需手动将composer.bat所在目录（如C:\ProgramData\ComposerSetup\bin）加入系统变量Path，并重启终端；同时检查%APPDATA%\Composer\config.json是否丢失并重配镜像。
系统还原后 composer 命令直接报“不是内部或外部命令”
这不是 Composer 被删了，而是 PATH 里指向它的那一段路径被还原清空了。Windows 系统还原会重置环境变量（尤其是用户变量），但不会动你硬盘上已有的文件——composer.bat 和 composer.phar 很可能还在原处，只是命令行找不到它们。
验证方法：打开文件资源管理器，手动导航到你当初放 composer.bat 的目录（比如 C:\bin），双击它——如果弹出版本信息，说明二进制完好；如果报错“找不到 php.exe”，说明 PHP 的 PATH 也丢了，得先修 PHP。
- 先运行
php --version，失败则回头补 PHP 的 PATH（路径如C:\xampp\php或C:\php） - 再确认
composer.bat所在目录（如C:\bin）已加进系统 PATH，不是用户 PATH（系统还原常清用户变量） - 必须重启所有已打开的 CMD/PowerShell 窗口，旧进程不会自动读新 PATH
- 别依赖“安装器勾选了 Add to PATH”——还原后这一步大概率失效，必须手动重配
composer config -g repo.packagist 镜像配置突然失效
系统还原会把 %APPDATA%\Composer\config.json 这个全局配置文件一起干掉。你之前设的阿里云镜像、缓存路径、GitHub OAuth token 全都没了，composer install 会立刻切回慢如蜗牛的 packagist.org。
重点：别信 composer config -g 的输出——它可能显示空对象或报 Key not exist，因为配置文件根本不存在了。你得先确认文件是否存在：dir %APPDATA%\Composer\config.json（CMD）或 Test-Path $env:APPDATA\Composer\config.json（PowerShell）。
- 重新写入镜像：执行
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/（注意末尾斜杠✅） - 如果提示
Could not write to …，加--no-plugins重试 - 验证是否真写进去了：运行
composer config -g repo.packagist，必须输出完整 JSON 对象，不是空行也不是 null - 项目级配置不受影响（它存在
composer.json里），但全局配置没了就得重来
COMPOSER_CACHE_DIR 临时缓存路径不再生效
系统还原不碰环境变量本身，但它会重置你的 shell 启动脚本（比如 PowerShell 的 $PROFILE）或 CI 脚本里的 set COMPOSER_CACHE_DIR=... 行——这些设置只在当前会话有效，还原后新开的 CMD 就没了。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
最典型的假象是：你记得自己设过 COMPOSER_CACHE_DIR，composer diag 却仍显示 Cache directory: C:\Users\xxx\AppData\Local\Composer\cache。这不是 Composer 没读到，而是变量压根没设进去。
- Windows CMD 中临时设置：运行
set COMPOSER_CACHE_DIR=C:\temp\composer-cache，然后立刻mkdir C:\temp\composer-cache - PowerShell 中要用
$env:COMPOSER_CACHE_DIR="C:\temp\composer-cache" - 验证唯一方式：执行
composer diag，盯住Cache directory:那一行是否匹配；再进磁盘看C:\temp\composer-cache下是否有files\或repo\子目录生成 - 权限比路径更重要：哪怕路径对了，如果当前用户没写入权，Composer 会静默 fallback 到默认位置，且不报任何错
为什么 composer self-update 总是卡在 Updating to version xxx…
系统还原后，Composer 的 vendor 目录（如果装在全局）可能残留旧版结构，但更大概率是 HTTPS 证书链或 DNS 缓存出了问题——尤其当你用的是自签名代理或企业防火墙，还原后系统时间/证书存储区可能未同步更新。
别急着重装，先排除网络层干扰：
- 运行
composer diagnose，重点看HTTPS is available和HTTP proxy support是否为OK - 如果提示
cURL error 60，说明 openssl 扩展或 CA 证书包异常，执行php -m | findstr openssl确认扩展已加载 - 临时绕过 SSL 验证（仅调试）：
set COMPOSER_DISABLE_TLS=1（CMD）或$env:COMPOSER_DISABLE_TLS="1"（PowerShell），再试self-update - 真正该做的是：升级 PHP 自带的 CA 包（从 https://curl.se/ca/cacert.pem 替换
php.ini里curl.cainfo指向的文件）
系统还原后最易忽略的，是它同时清掉了 Windows 的证书信任列表和 PHP 的 CA 证书缓存——这两者不一致时，Composer 会在 TLS 握手阶段卡死，表现就是 self-update 或 install 永远停在 “Updating…” 或 “Loading repositories…”。
