重装系统后 composer config -g repo.packagist 无效，主因是 ~/.composer/config.json 不存在、权限错误或内容损坏；需手动创建目录并执行全局配置，或改用项目级配置更可靠。
重装系统后 composer config -g repo.packagist 无效？检查 ~/.composer/config.json 是否为空或残留旧配置
重置系统后，composer config -g repo.packagist 看似执行成功，但 composer install 仍走 https://packagist.org，大概率是 ~/.composer/config.json 文件不存在、权限错误，或内容被清空/损坏。Composer 全局配置依赖该文件存在且可写，否则所有 -g 操作静默失败。
- 先确认文件是否存在：
ls -l ~/.composer/config.json；若报“no such file”，说明 Composer 还没初始化过全局配置 - 手动创建目录（如果缺失）：
mkdir -p ~/.composer，再运行composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 验证是否写入：
cat ~/.composer/config.json | grep url，输出应含"url": "https://mirrors.aliyun.com/composer/"，而非"https://packagist.org" - Windows 用户注意路径：
%APPDATA%\Composer\config.json，别误查C:\ProgramData\ComposerSetup\下的安装器配置
项目级配置比全局更可靠，尤其重装后环境不一致时
重装系统后，PHP 版本、用户身份、终端会话都可能变化，全局配置容易因权限或路径错位失效。此时直接在项目根目录下设镜像，绕过全局层干扰，是最稳的兜底方案。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 进项目目录，运行：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（不加-g） - 这条命令会自动向
composer.json的"repositories"字段写入键为"packagist"的对象；若原composer.json中"repositories": []，需先手动改为"repositories": {}，否则报错 - 确认生效：
composer config repo.packagist应输出完整 JSON 对象，且composer install -vvv日志首行显示Loading composer repositories with package information from https://mirrors.aliyun.com/composer/ - 好处：不受
COMPOSER_HOME路径变更影响，不依赖用户级配置文件读写权限
重装后 vendor/ 或 cache 目录权限错乱？别 chmod -R 777，用 chown 归还归属
重装系统后首次运行 composer install 报 Permission denied，常见于之前用 sudo 执行过命令，导致 vendor/、composer.lock 或 ~/.composer/cache 归属变成 root，而当前用户无权修改。
- 定位问题目录：看报错里带路径的那一行，比如
file_put_contents(/home/user/myapp/vendor/autoload.php): Permission denied→ 错在vendor/ - 查归属：
ls -ld vendor/，若第一列显示root root，就是所有权错配 - 修复命令：
sudo chown -R $USER:$USER vendor/（Linux/macOS）或icacls vendor/ /reset /T（Windows，需管理员 CMD） - 全局缓存同理：
sudo chown -R $USER:$USER $(composer config --global cache-dir) - 绝对禁用
chmod -R 777：它破坏可执行文件权限（如vendor/bin/phpunit），CI 和安全扫描会直接拒收
重装后 PATH 失效或超长？优先用绝对路径调用，避开环境变量污染
重装系统后，composer 命令本身可能报 'composer' is not recognized，或 composer global require 安装的命令（如 laravel）找不到——这通常不是 Composer 没装，而是 Windows PATH 被重置、长度超限，或路径指向了旧位置。
- 先验证
composer.bat是否还在：dir %PROGRAMDATA%\ComposerSetup\bin\composer.bat（Windows）或which composer（Linux/macOS） - Windows 用户：把
%PROGRAMDATA%\ComposerSetup\bin加入系统 PATH，**不要加%APPDATA%\Composer\vendor\bin多次**——这是最常引发CreateProcess failed的原因 - 更稳妥方式：不依赖 PATH，直接用绝对路径调用全局命令，例如：
"%APPDATA%\Composer\vendor\bin\laravel.bat" new myapp - Linux/macOS 用户：若
~/.composer/vendor/bin已加入 PATH，检查是否重复添加，用echo $PATH | tr ":" "\n" | grep composer排查
~/.composer/config.json 是否真实存在且可写，以及 vendor/ 目录的归属是否仍是当前用户——这两点不确认，换镜像、清缓存都白忙。
