直接结论：composer拆单体应用失败主因是运行时上下文未绑定，而非依赖未安装；需严格配置path仓库、收敛psr-4命名空间、用接口契约替代硬编码引用，并确保私有包子依赖可被解析。
直接用 Composer 拆单体应用的依赖拓扑，90% 的失败源于没处理好“运行时上下文绑定”——不是包没装上，而是类加载了、容器没注册、Facade 调不了。
为什么 composer require 自己的业务模块总报 Class not found 或 BindingResolutionException
因为业务模块不是工具库，它活在 Laravel/Symfony 的运行时里：要访问 request()、读 config('app.debug')、依赖数据库连接和中间件栈。一旦打成 Packagist 包：
-
IlluminateContractsContainerBindingResolutionException是常态——vendor 里的包没注册进主应用容器 - 每次改
src/OrderService.php都得composer update app/order-module+ 清缓存 + 重启队列 -
autoload-dev和主项目 PSR-4 映射重叠，dump-autoload后类找不到是大概率事件 - 测试必须启动整个 Web 应用，CI 单次跑测试动辄 3 分钟起步
path 仓库配置的三个硬条件，缺一不可
否则 vendor/ 下不会生成软链接，模块根本不会被加载：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
repositories中的url必须指向含合法composer.json的具体子目录（如"./modules/order"），不能只写"./modules/*"（除非你用的是 Composer 2.2+ 且每个子目录都有composer.json） - 子模块的
composer.json必须有非空name字段，且格式为"myapp/order-module"，和根项目require中的包名完全一致 - 根项目的
require里不能写"myapp/order-module": "^1.0"这类带版本约束的写法——本地path包不走版本解析，必须统一用"@dev"或"*"
autoload 怎么配才不炸？命名空间必须收敛
这是最容易踩的坑：所有模块都写 "psr-4": {"App": "src/"}，最后只有最后一个生效，AppModelsUser 可能从订单模块里加载，而不是用户模块。
- 每个模块的
autoload必须收敛到自身命名空间，例如订单模块写："MyApp\Order\": "src/" - 绝对禁止在模块内硬编码引用主项目命名空间（如
new App\Models\User），契约只能通过接口或 DTO 传递 - 模块的
composer.json里不要出现require-dev或测试框架依赖（如phpunit/phpunit），否则会污染主项目vendor/ - 执行
composer update myapp/order-module后，Composer 会在vendor/myapp/order-module创建符号链接，既保持物理隔离，又享受自动加载
私有包里写了 require，为什么项目里装不上？
错误往往不指向你的私有包，而是它的子依赖——比如你的 myorg/utils 声明了 "nesbot/carbon": "^2.60"，但项目没配对应仓库源，Composer 就会报 Could not find package nesbot/carbon。
- 必须确保所有间接依赖都可通过已配置的仓库获取（包括 Packagist、私有 Satis / Toran / GitHub Packages）
- 用
composer config --list确认repositories是否生效；私有仓库需带type: "composer"和有效url - 如果某个子依赖版本有问题（如
guzzlehttp/guzzle的7.5.0有内存泄漏），用conflict干预解析："conflict": { "guzzlehttp/guzzle": "7.5.0" }
真正落地的解耦，不是靠 composer require 把代码挪出去，而是靠 path + 精准 PSR-4 + 接口契约让模块“可替换、可热更、可独立测试”。最常被忽略的，是模块间的数据契约——DTO 传参还是接口注入，决定了你后续能不能真的把订单模块替换成另一个实现，而不是换个名字继续耦合。
