Packagist仅索引公开Git仓库中符合规范的composer.json，name必须为小写vendor/name格式、type显式设为library、autoload至少配PSR-4且路径真实存在、不填version字段；版本仅认带v前缀的已推送Git tag。
Packagist 不托管代码，只索引公开 Git 仓库里的 composer.json；你本地写完就 push，不打 tag、不配 webhook、name 格式错，包根本不会被识别——这不是延迟问题，是根本没通过校验。
composer.json 必须填对的四个字段
很多人跑通本地 composer install 就以为万事大吉，结果提交到 Packagist 后显示 “Package not found in VCS” 或 “Invalid composer.json”。核心就卡在这四个字段：
-
name必须是小写vendor/name格式（如myname/my-awesome-package），且vendor要和你在 Packagist 注册的用户名完全一致；MyName/MyPackage、my_name/my-package都非法 -
type显式设为library（别留空、别填project，否则 Packagist 直接忽略） -
autoload至少配psr-4，例如{"MyName\MyAwesomePackage\": "src/"}；必须确保src/目录真实存在，且内部有匹配命名空间的子目录（比如src/MyAwesomePackage/Helper.php） - 别写
version字段——Packagist 完全忽略它，版本只认 Git tag
Git tag 不带 v 前缀或没推送，Packagist 就看不到版本
Packagist 不监听分支，只抓取 Git tag。你 git push origin main 十次，它也只显示 dev-main，用户 composer require 时还得加 @dev，极不友好。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 打 tag 必须带
v前缀：git tag v1.0.0，不是git tag 1.0.0 - tag 必须推送到远程：
git push --tags（或git push origin v1.0.0） - 如果改了
composer.json又想重发同版本，先删远程 tag：git push origin :v1.0.0，再删本地：git tag -d v1.0.0，最后重新打+推 - GitHub 仓库页面要能点开看到
v1.0.0标签页，并关联到正确 commit
Packagist 提交后没同步？检查 webhook 和手动 Update
首次在 Packagist 点 “Submit” 后，它只会抓取一次。后续新 tag 不会自动出现，除非你主动触发或配好 webhook。
- 提交后去你的包页面，右上角点
Update（不是Submit），强制拉取最新 tag - 更可靠的是配 GitHub webhook：Settings → Webhooks → Add webhook，Payload URL 填 Packagist 提供的地址（类似
https://packagist.org/api/github?username=myname），Content type 选application/json，事件勾选Releases（不是Pushes） - 配完检查 GitHub Webhooks 页面是否显示 “Last delivery: 2xx”；若失败，常见原因是 Packagist 账户邮箱未验证，或 token 权限不足
- 私有仓库无法被 Packagist 索引，必须是 public
本地验证安装比等 Packagist 同步更快更准
别等 Packagist 页面刷新、别等别人反馈“Class not found”，自己用三行命令就能验证是否真能装、真能用：
- 新建测试目录：
mkdir test-app && cd test-app && composer init -n - 临时拉取开发分支：
composer require myname/my-awesome-package:dev-main（注意加:dev-main） - 写个
test.php，require 'vendor/autoload.php'，然后调用你的类，看是否报Class not found - 如果这一步失败，90% 是
autoload路径或命名空间不匹配，和 Packagist 无关
最容易被忽略的其实是 autoload 路径和命名空间的物理对应关系：PSR-4 不是“声明了就能用”，它要求文件路径必须严格反映命名空间层级。比如 "MyName\MyPackage\": "src/"，就必须有 src/MyName/MyPackage/Helper.php，而不是 src/Helper.php——后者即使 composer dump-autoload 成功，运行时照样找不到类。
