Composer不按require顺序安装包，而是基于依赖图拓扑排序：先解析所有包的require字段构建有向图，再按依赖关系确定处理顺序，确保每个包仅在其所有依赖就绪后才被处理；同一依赖图每次结果一致，且中文包名不影响加载，真正导致冲突的是PSR-4前缀重叠或私有仓库repositories顺序配置错误。
Composer 不按 require 顺序安装包，而是按依赖图拓扑排序
你看到 composer.json 里 "require" 列表从上到下写的是 A、B、C，就以为 Composer 会先装 A 再装 B —— 这是常见误解。实际它根本不看这个顺序，而是解析所有包的 composer.json 中的 require 字段，构建出一张有向依赖图，然后执行拓扑排序：只有当 X 的所有依赖都已确定版本并准备好，X 才会被处理。
这意味着：
- 即使你把
monolog/monolog写在require第一行，如果它依赖的psr/log还没被选中版本，Composer 就不会“先装 monolog” - 拓扑序是唯一解，不是随机或可配置的；同一依赖图每次运行结果一致
-
composer update --with-dependencies可能触发更深层的重算，导致看似“顺序变了”，其实是整个图被重新求解
中文包名不影响加载，但 PSR-4 前缀重叠会导致 fatal error
所谓“中文包安装顺序有误”，90% 是误判。Composer 对包名里的中文字符（如 my-company/用户中心）完全无感 —— 它只认 vendor/name 格式，且强制要求 ASCII。真正出问题的，往往是开发者手动改了 vendor 目录结构，或在多个包里用了相同命名空间前缀，比如都声明了 "App\": "src/"。
这种情况下 PHP 解析器会在第二次 require 同名类时直接报 Fatal error: Cannot declare class AppHelper，不是“加载慢”，是硬性终止。
检查要点：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 运行
composer dump-autoload -v，确认冲突的命名空间是否同时出现在autoload_psr4.php中 - 用
composer show -a vendor/package查该包实际注册的 PSR-4 前缀，注意末尾必须带反斜杠："App\": "src/"✅，"App\": "src"❌ - 删掉
vendor/composer/autoload_psr4.php，只留autoload_classmap.php，如果错误消失，说明纯属 PSR-4 前缀撞车
想让某个包“优先生效”，得动 autoload 映射，不是调安装顺序
安装顺序 ≠ 类加载顺序。你想让 myorg/utils 的 MyOrgUtilsHelper 比项目自身的 AppHelper 先被 new 找到？靠改 require 顺序没用。关键在 PSR-4 匹配逻辑：PHP autoloader 按最长前缀匹配，不是按注册先后。
所以正确做法是：
- 确保
myorg/utils的 autoload 配置前缀比你的项目更具体，例如"MyOrg\Utils\": "vendor/myorg/utils/src/"，而不是宽泛的"MyOrg\": "vendor/myorg/utils/src/" - 若必须覆盖项目同名类，可在
public/index.php开头用ClassLoader::prependPsr4()插入更高优先级映射，但这是运行时干预，非 Composer 配置范畴 - 绝对不要在项目
composer.json的autoload里把两个不同 vendor 包的源码目录映射到同一前缀下（如都塞进"App\": "vendor/pkg-a/src/"和"App\": "vendor/pkg-b/src/"）
私有仓库顺序错位，才是真·顺序问题
如果你用的是私有 Git 仓库或 Satis 服务，那 repositories 数组顺序才真正决定“谁先被选中”。Composer 查包是线性短路：从数组第一个元素开始，只要某个仓库的 packages.json 里声明了你要的包（哪怕只有 dev-main），就立刻采用，后面全跳过。
典型踩坑点：
- 没加
{"packagist.org": false}，导致私有源放第一行也无效 —— Composer 仍会隐式把 packagist.org 当兜底源插在最后 -
repositories写成关联数组（键值对）而非索引数组，结果只有最后一个仓库生效 - 私有源类型写错：GitLab 地址配成
"type": "composer"，应为"type": "vcs"；Satis 地址配成"type": "vcs"，应为"type": "composer" - 私有源的
packages.json缺少具体版本元数据（只有 provider 声明），Composer 就当它不存在
最稳验证法：运行 composer show -a vendor/package，看输出里 source 字段指向哪个 URL —— 这才是真实生效的来源，别猜。
