Composer怎么做包的命名规范_Composer包名命名规则说明【基础】

Composer包名必须为全小写vendor/package格式，是PHP生态全局唯一标识；含大写、下划线、单段或非法字符将导致install硬拦截及后续Class not found。 Composer 包名写错， 直接报 ，不是警告，是硬拦截；后续 问题八成也源于此——name 字段不是“起个名字”，它是整个 PHP 生态里包的全局唯一标识符，错一个字符就卡死。 name 字段必须是 vendor/package 格式且全小写 Composer 只读 里的 字段，不看目录名、Git 仓库名、GitHub 用户名。它必须严格满足两段式： ，中间仅一个 ，且全部小写。 ✅ 合法：vendor 是 （需与 Packagist 账号完全一致），package 是 （kebab-case） ❌ 非法：含大写字母， 立即失败 ❌ 非法：单段，Composer 自动补成 ，但 不是合法 vendor，别人 时无法解析 ❌ 非法：含下划线，Linux + Git 下 autoload 易失效 允许的字符仅限：小写字母、数字、 、 、 ；禁止空格、 、 、 、 、大写字母。 vendor 名必须和 Packagist 账号完全一致 你在 Packagist 注册的用户名（如 GitHub 用户名 ），就是 的唯一合法值。填错就等于身份证号写错，别人 永远拉不到你。 不能用邮箱（ ）、项目代号（ ）或系统用户名代替 域名反写可用（如 ），但需先在 Packagist 完成组织认证 、 、 是保留字，虽不报错，但 Packagist 提交时大概率被拒 本地开发别依赖 自动推断——它可能把目录 推成 ，而 不是你账号。 Composer 2.9.6 Composer 2.9.6 是 PHP 生态中高效、稳定的依赖管理工具。此版本在性能与兼容性上进一步优化，改进了依赖解析算法，提升大型项目中的安装与更新速度。它支持并行下载任务，显著减少等待时间，并增强了与私有仓库及镜像源的交互稳定性。同时修复了多项命令行交互与内存使用相关的缺陷，确保在复杂依赖关系下依然可靠运行。无论是新项目初始化还是现有系统维护，Composer 2.9.6 都能为开发者提供流畅、精准的依赖管理体验。 下载 package 名影响 PSR-4 命名空间推导，但不可依赖默认 如果你没显式配置 ，Composer 会按 机械转驼峰：如 → 。但这只是建议，实际代码若用 ，类就永远找不到。 必须显式写死 （注意末尾 ） 命名空间前缀末尾漏掉反斜杠（写成 ）会导致整个映射失效 package 含数字（如 ）→ 转成 ，但你文件里写了 ，Linux 下直接 改完 后，必须同步更新 、所有 声明、文件路径，再运行 ，否则缓存仍按旧规则加载。 本地验证 name 是否合规的最快方式 别等提交到 Packagist 才发现被拒，三步本地就能确认： 运行 —— 过不去说明格式或字符非法 删掉 和 ，再执行 —— 看是否真能装进本地 检查 里生成的映射项，是否和你预期的命名空间、路径完全一致 最常被忽略的是：改了 却没删 ，Composer 会复用旧缓存，导致 产出错误映射，问题藏得深、查得慢。