答案是包未在当前源中被识别，原因包括包名错误、镜像未同步、版本不稳定或私有仓库未配置；需验证包名准确性、检查Packagist页面、清除缓存、测试镜像同步状态、调整稳定性约束或正确配置repositories。
“Package not found”或“Could not find package”不是网络问题，也不是 Composer 坏了，而是它根本没在当前配置的源里查到那个包的元数据——删 vendor、清缓存、重试 install，90% 无效；得先确认源有没有、包存不存在、版本是否被过滤。
composer show -a 查不到包？先验证当前源是否生效
运行 composer show -a vendor/name 返回空或 “Package not found”，不代表包不存在，只说明 Composer 当前用的源里没这条记录。常见原因有：
- 项目级
composer.json里写了"repositories"字段，会直接屏蔽全局镜像（哪怕你配了阿里云） - 全局镜像配置失败：运行
composer config -g repo.packagist，输出应是完整 JSON，如{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}；若为空、null或报错，说明根本没配成功 - 镜像 URL 末尾漏了
/，比如写成https://mirrors.aliyun.com/composer（少斜杠），Composer 会静默 fallback 到官方源 - 用了已下线镜像（如 Laravel China 镜像 2023 年已停服），但配置还在
临时验证是否源的问题：运行 composer show -d repo.packagist=composer vendor/name 强制走官方源，如果能查到，就坐实是本地镜像配置或同步问题。
curl 直接查镜像 API 确认包是否存在
别信 composer clear-cache —— 它不清理 provider 元数据缓存，而这个缓存才是决定“看不看得见新包”的关键。最准的方式是绕过 Composer，直接用 curl 查镜像返回：
- 执行
curl -I https://mirrors.aliyun.com/composer/p/vendor/name.json，看状态码是不是200，Last-Modified时间是否接近当前时间 - 若返回
404或空 JSON，说明镜像还没同步该包（尤其新 tag、dev-main分支常被延迟或过滤） - 对比官方源：
curl -s https://packagist.org/packages.json | jq -r '.lastModified'，再查镜像的同字段，差超过 30 分钟基本可判定同步滞后
确认是镜像延迟后，手动删 provider 缓存目录才有效：rm -rf ~/.composer/cache/repo/https---mirrors.aliyun.com-composer（Linux/macOS）或 %APPDATA%\Composer\cache\repo\https---mirrors.aliyun.com-composer（Windows）。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
私有 Git 包报 Could not find package？检查 repositories 配置完整性
私有包报错 404，90% 是 repositories 配置缺字段或格式错，Composer 会静默忽略整条配置，继续查默认源。必须确保：
-
"type"明确写为"vcs"（不能省略，也不能写成"git"） -
"url"是完整 Git 地址，含.git后缀，如"https://github.com/myorg/mylib.git" - 仓库根目录的
composer.json里"name"字段格式为vendor/name，且与require时完全一致（大小写敏感） - 若用 GitHub/GitLab 私有库，URL 中不要带用户名和密码（如
https://user:token@github.com/...），否则auth.json会被跳过；应改用 token 认证 + 正确auth.json格式
验证分支是否存在：git ls-remote --heads https://github.com/myorg/mylib main；若无输出，说明远程根本没有 main 分支，dev-main 就不可能装上。
装上了却提示 Class not found？autoload 没生效或入口路径错
依赖安装成功但运行时报 Class not found，不是包没装，而是自动加载机制断了。常见于：
-
vendor/autoload.php没被正确引入：执行php -r "require 'vendor/autoload.php'; echo 'ok';"，不输出ok就说明 autoload 文件损坏或路径错 - 框架入口文件（如
public/index.php）里写的require __DIR__.'/../vendor/autoload.php'，但实际vendor不在上层目录（比如项目结构被移动过） - 某些包要求 PHP 扩展但未启用（如
ext-dom、ext-zip），导致其autoload规则未注册，composer dump-autoload也生成不了对应映射 - CI/CD 环境里用了
--no-scripts --no-plugins，跳过了post-autoload-dump钩子，需手动补composer dump-autoload
最易被忽略的是：PHP CLI 和 Web Server 加载的 php.ini 不同，php -m 看到的扩展，Web 页面里可能根本没启用——务必用 php --ini 和 phpinfo() 分别确认。
