Composer会忽略根composer.json中require自己包名的条目，不安装也不报错；它跳过与当前项目name完全匹配的依赖项，真正生效的是autoload配置（如psr-4），而非自引用。
自引用包在composer.json中require自己会怎样
Composer 允许你在根 composer.json 的 require 里写上自己项目的包名（比如 "myorg/myapp": "dev-main"），但这种写法不会触发“安装自己”，也不会导致循环依赖报错——它会被 Composer 完全忽略。原因很简单：Solver 在构建依赖图时，会跳过所有与当前项目 name 字段完全匹配的 require 条目。
常见错误现象：
- 本地
composer install成功，但 CI 上报Class not found→ 很可能是因为你误把自引用当成了 autoload 补丁，实际 autoload 并未覆盖自身代码路径 - 执行
composer show --tree看不到自己项目名 → 正常，它根本不在依赖树中，show --tree只显示 vendor 下真实安装的包
真正起作用的是 autoload 字段。如果你希望自己的源码能被自动加载，必须显式配置 psr-4 或 classmap，例如：
"autoload": {
"psr-4": {
"App\": "src/"
}
}
不这么做，哪怕你写了 "myorg/myapp": "dev-main"，vendor/autoload.php 也不会知道该去哪找 AppSomething。
为什么自引用无法用于强制锁定间接依赖版本
有人试图用自引用绕过依赖解析，比如在 composer.json 中加一行 "monolog/monolog": "2.10.0"，以为能“压住”某个间接依赖的版本。这行不通——Composer 的 Solver 会把它当作一个新请求，但不会改变已有依赖链中的约束优先级。如果 laravel/framework 要求 "monolog/monolog": "^2.11"，而你又写了 "monolog/monolog": "2.10.0"，Solver 就会直接判定冲突，报出 Your requirements could not be resolved...。
真正可控的方式只有三种：
- 用
conflict显式排除不想要的版本："conflict": {"monolog/monolog": " - 用
replace声明替代关系（适用于 fork 场景）："replace": {"monolog/monolog": "self.version"}，再配合 fork 包的composer.json声明provide - 升级或降级上游包（如换用
laravel/framework更老的 minor 版），让它的require自然兼容你的目标版本
注意：replace 和 provide 都必须写在被替换/提供的那个包自己的 composer.json 里，根项目里写无效。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
自引用 + type: project 是标准应用项目的事实约定
绝大多数 Laravel、Symfony 应用模板的 composer.json 都长这样：
{
"name": "laravel/laravel",
"type": "project",
"require": { ... }
}
这里的 "name" 不是“要装自己”，而是给 Packagist 标识用的；"type": "project" 才是关键——它告诉 Composer：别把我当库来处理，我不该被别人 require，也不该往 vendor/ 写我自己的代码文件（只装依赖）。
如果你删掉 "type": "project"，Composer 会把它当成 library，尝试把整个项目目录复制进 vendor/myorg/myapp/，造成路径混乱和 autoload 错位。更糟的是，某些插件或部署脚本会检查 type 字段来判断是否为可部署应用，填错会导致静默失败。
所以，不要为了“看起来整齐”而补上自引用 require；也不要为了“方便测试”临时改成 library 类型——这两者都偏离了 Composer 对 project 的设计契约。
自引用在 lock 文件里永远为空
composer.lock 的 packages 数组里永远不会出现你自己的项目名。即使你手动编辑 composer.json 加了自引用，运行 composer update 后，composer.lock 依然只记录 vendor 下真实安装的包。这是由 Composer 的快照机制决定的：lock 文件只保存“被安装的东西”，而项目自身不是被安装的依赖。
这意味着：
- CI 流程中不能靠
composer.lock检查项目自身版本 —— 它根本不存 -
composer show --tree或composer why查不到自己，不是 bug，是设计如此 - 想在运行时获取当前项目版本？得读
composer.json文件本身，或用ComposerInstalledVersions::getVersion('myorg/myapp')（前提是没设type: project；若设了，这个调用会返回null）
最容易被忽略的一点：当你把项目从 type: project 改成 type: library 并跑一次 composer update，lock 文件里依然不会有它——因为 Solver 仍认为“自己不是依赖”，只是 autoload 行为变了。这种改动带来的副作用，往往要等到部署后 Class not found 才暴露出来。
