90%的“could not find package”因name或路径不匹配；需确保大小写、分隔符、vendor名完全一致，且本地包composer.json合法、url指向含composer.json的目录。
自定义仓库配置后“could not find package”怎么办
90% 的原因是 name 字段或路径不匹配。Composer 不做模糊匹配，大小写、分隔符（只认短横线 -）、vendor 名必须逐字一致。
常见错误现象：Could not find package vendor/name，但运行 composer show --all 根本没列出该包。
- 检查本地包根目录下是否存在合法的
composer.json（无尾逗号、全双引号、JSON 语法有效） - 确认本地包
composer.json中的name值与主项目require里写的完全相同，例如"acme/utils"≠"Acme/utils"≠"acme_utils" -
url必须指向**含composer.json的目录**，且是相对于主项目composer.json的路径（如"../my-pkg"），不能加末尾/，也不能是 shell 当前工作目录下的相对路径 - Windows 用户避免路径含中文或空格；Docker 场景需加
--cap-add=SYS_ADMIN并确保挂载支持 symlink
为什么改了本地代码，vendor 里还是旧版本
因为 symlink 没真正生效，Composer fallback 到了 copy 模式——这是最隐蔽的调试陷阱。
关键不在主项目配 "symlink": true，而在于**本地包自己的 composer.json 是否声明了 "options": {"symlink": true}**。
- 缺这句，Windows 上即使管理员权限运行终端，也会静默 fallback
- 验证是否真用了 symlink：
ls -la vendor/vendor/name（Linux/macOS）或dir vendor\vendor\name（Windows），看到箭头或JUNCTION才是成功 - 若显示为普通文件夹，立刻检查本地包
composer.json的options段是否遗漏
依赖解析失败时别急着删 composer.lock
删 lock 文件抹掉了当前已知“能跑”的状态，反而让 Composer 从零瞎试，可能把问题变得更难定位。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
真正该做的是让 Composer 把推理过程摊开给你看：
- 运行
composer update --dry-run -v：不改任何文件，但完整走一遍求解逻辑，末尾明确指出冲突源头（比如两个包对symfony/console的版本要求互斥） - 翻输出最后 10 行，盯住
Found conflicting requirements和反复出现的包名（如monolog/monolog） - 用
composer why-not vendor/package:version查谁在拦路，用composer prohibits package-name查谁在拖后腿 - 加
--no-dev快速验证是否 dev 工具链（如phpunit/phpunit）导致冲突
autoload 不生效，不是 Composer 没加载，而是映射没更新
path 仓库让包“存在”，但类能否被 new 或 use，取决于 autoload 映射是否包含它的真实路径。
即使本地包 composer.json 写了 "psr-4": {"Acme": "src/"}，主项目也不会自动继承这个映射。
- 必须手动执行
composer dump-autoload -o更新自动加载器 - 如果用了 Xdebug 断点，要确保 IDE 中的路径与磁盘真实路径完全一致（尤其 Windows 下大小写和盘符）
- 修改本地包的
autoload配置后，主项目必须重新 dump，否则新命名空间不会被识别
最容易被忽略的是 symlink 和 autoload 的双重依赖：没 symlink 就改不了源码，没 dump-autoload 就用不到新代码——两步缺一不可。
