别人require不了你的包，大概率是composer.json不合规、Git tag没推或命名空间与路径不匹配；Packagist首次抓取仅校验name、type、autoload、license四字段，缺一或格式错即拒收。
别人 composer require 不了你的包，大概率不是网络或 Packagist 延迟问题，而是本地 composer.json 不合规、Git tag 没推、或者命名空间和文件路径对不上——这三处任一出错，Packagist 就根本不会收录，用户也压根搜不到。
composer.json 必填字段怎么写才不被 Packagist 拒绝
Packagist 第一次抓取时只校验四个字段：name、type、autoload、license。漏一个或写错格式，页面直接报 Invalid package information。
-
name必须是小写vendor/name格式，比如myname/my-awesome-package；MyName/MyPackage、my_name/my-package、myname/my_awesome_package全部非法 -
vendor部分必须和你在 packagist.org 注册的用户名**完全一致**（不是 GitHub 用户名） -
type显式写成"library"，别留空、别写project或package，否则 Packagist 直接跳过 -
autoload至少配psr-4，键必须带双反斜杠结尾："MyNameMyPackage\": "src/"；少一个或多一个/，后续类就加载失败 -
license不能空，得是 SPDX ID，比如"MIT"、"Apache-2.0"，写成"mit"或"MIT license"也会被警告
验证命令：composer validate。报错就别急着提交。
PSR-4 映射为什么总报 Class not found
Composer 不解析 PHP 文件内容，它只靠 composer.json 里写的路径去拼文件名。哪怕类定义完全正确，只要路径错一丁点，Class not found 立刻出现。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 假设
autoload.psr-4是"MyNameMyPackage\": "src/"，那new MyNameMyPackageCalculator()就会去找src/Calculator.php；如果类在src/MyPackage/Calculator.php，就必须把映射改成"MyNameMyPackage\": "src/MyPackage/" - 文件名必须和类名严格一致：类
Calculator→ 文件必须叫Calculator.php，calculator.php或calc.php都不行 - Linux 下大小写敏感，
src/myname/和src/MyName/是两个目录；Windows 可能“凑合能跑”，但上线后必挂 - 改完
composer.json后，必须手动运行composer dump-autoload -o，否则新映射不生效
为什么 git push 了还是 Could not find package
这不是 Packagist 没同步，而是它根本没识别出“稳定版本”。Composer 默认只装 stable 版本，而 Packagist 只认 Git tag，不认分支最新提交。
- 必须打带
v前缀的语义化 tag：git tag v1.0.0，不是git tag 1.0.0，也不是git tag release-v1.0.0 - tag 必须推到远程：
git push --tags或git push origin v1.0.0；只git push主干代码没用 - GitHub 页面要能点开看到
v1.0.0标签页，并关联到正确 commit；看不到标签 = Packagist 抓不到 - 首次提交后，Packagist 不会自动监听后续 tag，得配 GitHub webhook（Payload URL 填
https://www.php.cn/link/ec811d0d775adc62776ba80fadd4ed19/api/github，Events 选Just the push event）
临时调试可用：composer require myname/my-awesome-package:dev-main，但这只是绕过校验，不能当正式发布流程。
本地开发时如何快速验证包结构是否正确
别等推完再测，本地就能闭环验证：结构对、自动加载通、实例化不报错。
- 在包根目录下运行
composer dump-autoload -o，确保无报错 - 执行
php -r 'require "vendor/autoload.php"; new MyNameMyPackageCalculator();'，不报Class not found才算通过 - 想模拟别人安装效果？新建空目录，
composer init -n，然后composer require ./path/to/your/package（注意是相对路径） - 如果包含 CLI 工具，检查
bin/脚本第一行是不是#!/usr/bin/env php，且有可执行权限：chmod +x bin/mytool
最容易被忽略的是：你改了 composer.json 里的命名空间映射，却忘了同步调整文件路径；或者打了 tag 却没推，还在 GitHub 页面刷新等“自动更新”——Packagist 不主动拉，它只响应事件。
