私有包能否被命中取决于repositories数组顺序：必须将私有仓库置顶，显式添加{"packagist.org": false}，否则Composer短路匹配首个返回200且含目标包元数据的源，后续全跳过。
repositories 顺序决定私有包能否被命中
私有包装不上、同名包被公共源高版本覆盖，90% 是因为 repositories 数组顺序错了。Composer 不 fallback，只 short-circuit：从索引 0 开始逐个请求，只要某个源返回了包含目标包的元数据（HTTP 200 + packages.json 中有对应条目），立刻锁定该源，后续全跳过。
- 私有 Composer 仓库（
"type": "composer"）必须放在repositories数组第一位 - URL 必须以
/结尾，否则请求路径变成https://your.repo.compackages.json→ 404 → 直接切到下一个源 - 必须显式禁用 Packagist：
{"packagist.org": false}，否则即使你写了镜像，Composer 仍会在镜像返回 404 时自动回退到官方源 - 改完后删掉
composer.lock和vendor/，再跑composer install，否则旧 lock 文件会缓存错误源记录
autoload 中 files 的执行顺序是声明顺序
files 不参与类加载，只是全局脚本注入点，但它按 composer.json 中数组顺序 include_once 执行——前面的文件能被后面的覆盖（函数、常量、类定义），且一旦某个 files 报 ParseError，整个 autoload 初始化就失败，后续所有自动加载都不可用。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 多个
files按 JSON 数组顺序加载："files": ["a.php", "b.php"]→ 先include_once a.php，再include_once b.php - 如果
b.php里重新定义了a.php中的函数，且没加function_exists()防护，就会 fatal error -
files在psr-4和classmap之后注册，但它是“无条件立即执行”，不等类被访问
psr-4 冲突时靠命名空间前缀长度决胜
两个 psr-4 规则都能匹配同一个类名时，不是看配置顺序，而是看谁的命名空间前缀更长。Composer 会选最长前缀匹配的规则，这个逻辑由 ComposerAutoloadClassLoader::findFile() 实现，跟注册顺序无关。
-
"App\": "src/"和"AppHelper\": "lib/helper/"同时存在时，AppHelperUtils一定走lib/helper/Utils.php（前缀长度 13 > 5） - 若前缀长度相同（如
"A\"和"B\"），才按composer.json中psr-4数组的书写顺序遍历，先命中者胜 - 想“替换”第三方类？别动 autoload 顺序——
class_alias()或自定义spl_autoload_register回调才是正解
deploy:vendors 任务中 composer_action 不影响依赖解析顺序
Deployer 的 recipe/composer.php 只是把 deploy:vendors 插入到标准部署链中，并不改变 Composer 自身的依赖解析逻辑。真正控制加载行为的，仍是项目本地的 composer.json 和运行时环境。
-
composer_action（默认install）只决定执行哪个命令，不影响repositories或autoload解析顺序 -
composer_options若传了--no-dev或--prefer-dist，会影响最终安装内容和性能，但不改变元数据请求顺序 - 远程服务器上若未清理
vendor/和composer.lock，旧 lock 文件可能让deploy:vendors跳过实际解析，导致私有包未更新
files 是严格按声明顺序执行的，其余类型靠匹配规则或静态映射，不靠“优先级”。改错顺序，比调参数更能一击解决多数加载异常。 
