composer怎么创建自己的包_composer开发并发布扩展包教程

composer 识别本地包需在 repositories 中配置 path 类型源，路径须相对项目根目录且不能含空格；包名须为 vendor/name 格式、全小写加连字符；autoload 推荐 psr-4 并注意命名空间双反斜杠及路径正确性；发布到 packagist 需确保默认分支有合法 composer.json 并打版本 tag。

怎么让 Composer 识别你的本地包

Composer 默认只认 packagist.org 上的公开包，想让它加载你刚写好的代码，得先告诉它“这玩意儿就在本地”。最直接的办法是把 composer.json 里的 repositories 字段加上一条 path 类型源：

{   "repositories": [     {       "type": "path",       "url": "./my-awesome-package"     }   ] }

注意路径必须是相对当前项目根目录的，不能用 ../ 跨出项目范围；如果路径里有空格或特殊字符，Composer 会静默失败——不是报错，而是直接跳过这个源。

• 开发阶段建议始终用 path 源，改完代码不用 composer update 就能立刻生效（前提是没加 "symlink": true）
• 别在 repositories 里混用 packagist 和 path，容易触发缓存冲突，导致 composer require 找不到本地包
• 如果包目录下没有 composer.json，或者里面缺 name 字段，Composer 会直接忽略它，连警告都不给

package name 怎么起才不会撞车又符合规范

Composer 包名是全局唯一的标识符，格式为 vendor/name，比如 monolog/monolog。你不能随便写个 utils 或 mylib 就提交——Packagist 会拒绝，本地测试时也会让 composer require 失败。

• vendor 部分建议用 github 用户名或组织名，小团队就用个人名，别用公司全称（比如 acme-corp/tool 容易和别人重名）
• name 部分避免通用词：cache、log、helper 都已被大量占用，优先选带业务特征的，比如 acme-invoicing-formatter
• 全小写 + 连字符，别用下划线或大写字母，否则某些 linux 环境下会因大小写敏感导致自动加载失败

autoload 怎么配才能让类被正常找到

Composer 不会自动扫描你所有 PHP 文件，必须靠 autoload 字段明确告诉它“哪些文件对应哪些命名空间”。最常用的是 psr-4，但新手常在这里翻车：

{   "autoload": {     "psr-4": {       "AcmeInvoicing": "src/"     }   } }

关键点：命名空间末尾的双反斜杠 必须写全，少一个就加载失败；src/ 路径必须存在且是相对于包根目录的——不是项目根目录。

• 如果类文件放在 src/Formatter/InvoiceFormatter.php，那它的命名空间必须是 AcmeInvoicingFormatter，不能漏掉中间段
• 别为了省事用 files 自动加载单文件，它不支持命名空间，且每次请求都 require，影响性能
• 改完 autoload 后，一定要运行 composer dump-autoload，否则新配置不生效

发布到 Packagist 的实际卡点在哪

点几下按钮就能把 GitHub 仓库连上 Packagist，但真正卡住人的从来不是操作，而是权限和元数据校验：

• Packagist 只认 GitHub 仓库的默认分支（通常是 main 或 master）下的 composer.json，如果你把文件放在 dev 分支，它根本读不到
• 首次提交前，确保 composer.json 里有合法的 name、type（比如 library）、autoload，缺任意一项都会提示 “Invalid package information”
• 打 tag 是必须的：Packagist 不抓 commit，只认带版本号的 tag，比如 v1.0.0；用 1.0.0（没 v 前缀）也能识别，但最好统一风格

发布后别急着让别人 require，先在干净项目里试一遍 composer require vendor/name:dev-main，确认 autoload 和依赖都能走通——很多“发布成功但用不了”的问题，其实卡在本地没验证。