composer包名必须为vendor/name格式且全小写、仅含ascii字母数字及_-.,否则install报错；name是全局唯一标识，单段会被补为root/xxx导致依赖无法引用，大写字母在linux+git下引发autoload失败。
Composer 包名必须是 vendor/name 格式，且全部小写、仅含 ASCII 字母、数字、下划线、中划线和点；否则 composer install 会直接报错或无法解析依赖。
为什么 name 字段不能随便写成 my-project 或 MyPackage
Composer 不是“项目命名工具”，而是包管理器——name 是全局唯一标识，用于定位、下载、解析依赖关系。如果写成单段（如 my-project），Composer 会认为你没指定 vendor，自动补成 root/my-project，但这个 root 并不真实存在，导致其他包无法 require 它；如果含大写字母（如 MyPackage），部分 Linux 文件系统+Git 组合下会引发 autoload 失败（类文件找不到）。
- 错误示例：
"name": "MyAwesomeLib"→ 实际注册为root/MyAwesomeLib，别人 require 时得写"require": {"root/MyAwesomeLib": "^1.0"}，极难维护 - 正确写法必须两段：
"name": "acme/utils"、"name": "symfony/http-foundation" - vendor 名通常是你 GitHub 用户名、组织名，或品牌域名反写（如
example-com而非example.com）
name 中的 vendor 部分能用点号（.）吗？
可以，但只推荐用于域名反写场景，且必须转义为中划线或下划线——因为 Composer 内部把点号视为层级分隔符（类似 PSR-4 的命名空间映射），不是合法 vendor 字符。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 允许：
"name": "example-com/logger"（推荐） - 允许但易混淆：
"name": "example.com/logger"→ Composer 会警告 “invalid characters”，某些旧版本直接拒绝加载 - 禁止：
"name": "example..com/logger"或"name": "exa.mple/logger"（多个或中间点号） - 注意：GitHub 仓库名含点号（如
my.tool）不影响包名，包名仍应写成my-tool/tool这类规范形式
本地开发时 name 写错了，怎么快速修正又不破坏 autoload？
改 composer.json 的 name 后，必须同步更新 autoload 和已发布的代码引用点，否则 composer dump-autoload 会生成错误映射，类自动加载失败。
- 先改
composer.json的name，比如从old-vendor/lib改成new-vendor/lib - 立刻删掉
vendor/目录和composer.lock（否则 Composer 可能缓存旧 name） - 检查
autoload段是否还硬编码了旧 vendor（如"psr-4": {"OldVendor\": "src/"}→ 必须改成"NewVendor\"） - 运行
composer install，再执行composer dump-autoload -o确认映射生效 - 如果你已将该包发布到 Packagist，name 一旦发布就不可更改——只能发新包，旧包标记为 abandoned
最常被忽略的是 vendor 名与 GitHub 组织名不一致导致的协作混乱：团队成员 clone 下来后，composer install 没报错，但 vendor/autoload.php 加载不到自己的类——十有八九是 name 里 vendor 拼错了，或者 autoload 命名空间没跟着改。
