Composer如何创建并发布自己的开源PHP包到Packagist-composer-PHP中文网

packagist抓取失败或用户安装后类找不到，主因是composer.json的name格式错误（须vendor/name全小写且vendor与packagist账号一致）、autoload映射错位、version字段冗余、未打符合semver的git tag（如v1.0.0）及未配置github webhook自动同步。

composer如何创建并发布自己的开源php包到packagist

composer.json 必须写对，否则 Packagist 抓取失败或用户安装后类根本找不到

Packagist 不解析 composer.json 里的 version 字段，也不读分支最新提交——它只认 Git tag 和根目录下合法的 composer.json。最容易出问题的是字段缺失、命名空间映射错位、或 vendor 名和 Packagist 账号不一致。

name 必须是 vendor/name 格式，全小写，且 vendor 必须与你在 Packagist 注册的用户名完全一致（比如你在 Packagist 是 myname，就不能写成 MyName 或 my-name）
autoload 推荐用 PSR-4，映射必须严格匹配：如果写 "MyName\MyPackage\": "src/"，那 src/Helper.php 就得声明 namespace MyName\MyPackage;，少一个反斜杠或大小写错都会导致 Class not found
require 只放运行时依赖，比如 "php": "^8.0"；开发依赖（如 PHPUnit）必须进 require-dev
删掉 version 字段（它会被 Git tag 覆盖，留着反而可能干扰版本解析）
运行 composer validate 本地检查语法，比等 Packagist 报错再改快得多

打 git tag 才算真正发布，不是推代码就完事

Packagist 默认忽略 main 或 master 分支的任何改动，只从 tag 构建可用版本。没打 tag，包页面就会显示 “No releases found”，用户 composer require 默认装的是 dev-main，不是稳定版。

tag 名必须是语义化格式，推荐带 v 前缀：v1.0.0、v2.1.3、v3.0.0-beta.1
❌ 错误示例：1.0（缺补零）、release-v1.0.0（含前缀）、1.0.0-final（含后缀）
打 tag 后必须推送：git tag v1.0.0 -m "First stable release" → git push origin v1.0.0
如果你同时推了多个 tag，Packagist 会全部抓取；但用户 composer require vendor/name 默认拉最新 stable tag，不是最高数字

在 Packagist 提交仓库 URL 后，必须配 webhook 才能自动更新

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

别信“提交一次就一劳永逸”。旧教程说点几次 “Update” 就行，实际维护中几乎必然漏更。官方现在强推 GitHub/GitLab webhook 实时同步。

进入你的 GitHub 仓库 → Settings → Webhooks → Add webhook
Payload URL 填 @#@#@#@#@#@#@#@#@#@0
Event 类型选 Just the push event（或勾选 Releases，如果你用 GitHub Releases 发版）
保存后，下次 git push --tags，Packagist 页面右上角的 Last updated 时间几秒内就会变
如果没反应，去 webhook 的 Recent Deliveries 看状态码：200 表示成功，404 说明 URL 拼错或仓库私有，403 通常是权限不足（需确认 Packagist 已连接 GitHub 账户）

本地验证 composer require 是否真能用，别等别人反馈

很多人跳过这步，结果用户装上就报错，第一反应是“我代码没问题，肯定是他们环境不对”。其实 90% 的问题出在 autoload 映射或 tag 没推。

新建空目录：mkdir test-app && cd test-app && composer init -n
临时装 dev 版验证结构：composer require yourname/your-package:dev-main

写个最小测试文件：test.php，内容为：

<?php require_once 'vendor/autoload.php';
// 假设你导出的是 MyName\MyPackage\Helper
var_dump(class_exists('MyName\MyPackage\Helper'));

如果输出 bool(true)，说明 autoload 正确；否则立刻回查 composer.json 和文件路径
确认无误后再打正式 tag 并推送——这才是发布闭环里最不可跳过的动作

真正卡住人的，从来不是“怎么写”，而是 autoload 映射和 git tag 推送这两个动作是否干净、可验证。其他步骤出错都有明确报错，唯独这两处静默失败，用户一调用就 Class not found。

php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！