Composer PSR-4自动加载生效需同时满足三条件：composer.json中autoload为顶层键且格式正确、命名空间前缀以双反斜杠结尾并路径严格对齐、执行过composer dump-autoload。
path仓库配置必须严格满足三个硬条件
不满足任意一条，vendor/下就不会生成软链接，模块压根不会被加载——不是报错，而是静默失效。
-
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"
PSR-4映射必须收敛到模块自身命名空间
这是最常炸的点：所有模块都配"App": "src/"，最后只有最后一个生效。结果AppModelsUser可能从订单模块加载，而不是用户模块。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 每个模块的
autoload.psr-4必须收敛到自己命名空间，例如订单模块写"MyApp\Order\": "src/" - 模块内禁止硬编码引用主项目命名空间（如
new AppModelsUser），契约只能通过接口或 DTO 传递 - 模块的
composer.json里不要出现require-dev或phpunit/phpunit，否则会污染主项目vendor/
改完配置后必须手动执行composer dump-autoload
很多人以为改了composer.json就自动生效，其实不是。Composer 的映射表是静态生成的，存在vendor/composer/autoload_psr4.php里，它不会监听文件变化。
- 新增类、修改命名空间、调整路径后，不运行
composer dump-autoload，映射表里就没有这条记录，必然Class not found - 路径结尾缺
/、命名空间结尾缺、大小写不一致——这些错误不会报错，但会导致路径拼接失败，最终require找不到文件 - CLI 脚本和 Web 入口（如
index.php）都得各自显式引入require 'vendor/autoload.php'，作用域不共享
模块物理隔离 ≠ 业务逻辑解耦
path + PSR-4 只解决“代码怎么加载”，不解决“依赖怎么切”。业务模块天然依赖框架上下文，硬打包会触发IlluminateContractsContainerBindingResolutionException等容器绑定失败问题。
- 模块不能直接调用
request()、event()或读config('app.debug')，这些必须抽象成接口由主应用注入 - 数据库连接、中间件栈、队列驱动等运行时能力，需通过契约层传递，而非隐式依赖 Laravel/Symfony 内部实现
- 本地开发改
src/OrderService.php后，不需要composer update+ 清缓存 + 重启队列——改完即生效，前提是 autoload 配对且无硬依赖
Class not found里无声崩塌。 
