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": {
"Acme\Invoicing\": "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 和依赖都能走通——很多“发布成功但用不了”的问题，其实卡在本地没验证。
