项目级 repositories 字段会彻底屏蔽全局镜像，只要 composer.json 中存在该字段，Composer 就完全忽略全局 repo.packagist 配置；全局配置需满足四条件才生效：带 -g 参数、键名为 repo.packagist、显式声明 type、URL 为 HTTPS 且末尾带 /；推荐使用项目内配置确保协作与部署一致性。
项目级 repositories 字段会彻底屏蔽全局镜像
只要项目根目录的 composer.json 里存在 repositories 字段，无论其值是 {}、[] 还是 {"packagist.org": false}，Composer 就完全跳过读取全局配置中的 repo.packagist ——不是“优先级低”，而是压根不看。这导致你在 CI 脚本里用 sudo composer config -g repo.packagist ... 配了全局源，但构建进程以 www-data 用户运行，根本访问不到 /root/.composer/config.json；或者你在宝塔面板后台执行命令，默认是 www 用户，而你本地终端配的全局镜像对它无效。
验证方式很简单：composer config -g repo.packagist 必须输出完整 JSON 对象，如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。如果返回空、null、Key not found 或只有一行 URL，说明没写进去，立刻重试。
composer config -g repo.packagist 的四个硬性生效条件
这条命令看似简单，但缺一不可：
- 必须带
-g（或--global）参数 - 键名必须是
repo.packagist（写成repos.packagist或packagist.org都无效） -
url值里的type必须显式写出，不能省略或当注释用 - URL 必须是 HTTPS 且末尾带
/，例如https://mirrors.aliyun.com/composer/✅，少斜杠会触发/composerpackages.json 404
全局配置实际落盘在：~/.composer/config.json（Linux/macOS）或 %USERPROFILE%\AppData\Roaming\Composer\config.json（Windows）。手动编辑该文件时，一个逗号错位或引号未闭合，Composer 就会静默忽略整个配置段。
项目内配置才是协作与部署的唯一可靠方式
进项目根目录后运行：composer config repo.packagist composer https://mirrors.aliyun.com/composer/（注意：去掉 -g），它会把镜像写进 composer.json 的 repositories 对象中，key 固定为 "packagist"。这种方式不会被用户环境干扰，CI 流水线拉代码即生效，同事 clone 后无需额外配置。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
如果你同时用了私有仓库（比如 Artifactory 或 Satis），还必须显式禁用默认源："packagist.org": false 必须作为同级字段写在 composer.json 顶层，不能塞进 repositories 数组里。Artifactory 的 URL 末尾斜杠也不能省，否则请求 packages.json 直接 404。
全局 vs 局部安装的二进制调用逻辑完全不同
全局安装（如 composer global require laravel/installer）生成的可执行文件放在：~/.composer/vendor/bin/（Linux/macOS）或 %APPDATA%\Composer\vendor\bin\（Windows）。这个路径不在系统 PATH 中，所以命令会报 command not found ——不是装失败，是找不到入口。
项目内安装（如 composer require phpunit/phpunit）的可执行文件只在 ./vendor/bin/phpunit，必须显式调用：./vendor/bin/phpunit（Linux/macOS）或 vendor\bin\phpunit（Windows）。想简化？在 composer.json 的 scripts 字段加一条："test": "php vendor/bin/phpunit"，之后直接 composer test。
真正关键的分界线不是“工具 or 库”，而是“是否参与项目运行逻辑”：工具（如 php-cs-fixer）可全局装；运行时依赖（如 guzzlehttp/guzzle）必须项目内装；phpunit/phpunit 表面是工具，但常被 autoload-dev 或 phpunit.xml 引用，版本敏感，也应项目内装。
