Composer 的 name 字段仅支持 ASCII 字符，禁止中文；应使用 kebab-case 英文命名（如 acme/user-management），中文语义通过 description 字段表达，并同步更新 PSR-4 命名空间映射。
Composer 不支持中文命名。
name 字段只接受 ASCII 字符：小写字母、数字、短横线 -、下划线 _、点号 . 和斜杠 /。任何中文字符（包括汉字、全角标点、中文空格）都会导致 composer validate 直接失败，报错类似：
Invalid package name "myvendor/用户管理": Invalid character in package name
这不是警告，是解析中断 —— Composer 根本不会继续读取这个 composer.json。
name 字段为什么不能用中文
- Packagist 后端校验强制拒绝非 ASCII 字符，提交页面直接拦截
- URL 安全性要求：包名会出现在下载链接、API 路径、缓存键中（如
<a href="https://www.php.cn/link/cb8423d6c3fefb35cad0c10f334f7e33">https://www.php.cn/link/cb8423d6c3fefb35cad0c10f334f7e33</a>会被拒） - Git 文件系统在多数环境中不处理 UTF-8 文件名的大小写/编码一致性，容易引发
Class not found - PSR-4 自动加载器依赖文件路径与命名空间映射，而 PHP 命名空间本身也不允许中文（语法错误）
中文语义怎么体现？用 kebab-case 拆解翻译
你不能写 "name": "acme/用户管理"，但可以写：
"name": "acme/user-management""name": "acme/order-processor""name": "acme/wechat-pay-sdk"
这是行业通用做法，也是 Packagist 上所有高星包的实际命名方式（如 symfony/http-foundation、laravel/framework）。
重点不是“直译”，而是准确传达功能 + 保持可读性 + 符合工具链约束。
常见对应关系：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 用户 →
user - 管理 →
management或admin（视场景） - 订单 →
order - 支付 →
pay或payment - 微信 →
wechat（不是weixin，因英文生态已形成惯例）
命名冲突或歧义时怎么办？
避免泛词（utils、tool、helper），优先用动宾结构或领域限定：
✅ acme/invoice-generator
✅ acme/pdf-report-renderer
❌ acme/pdf-helper（含义模糊）
❌ acme/invoice（太泛，易与其他发票包重名）
如果项目面向中文用户，可在 description 字段里写清楚中文说明：
"description": "生成标准电子发票的命令行工具（支持国税局 XML 格式）"
Packagist 页面会显示这段文字，搜索时也参与匹配 —— 这才是表达中文语义的正确位置。
真正容易被忽略的点：改名后 autoload.psr-4 映射必须同步更新，且命名空间前缀里的大小写和单词分隔不继承name 的 kebab-case 规则。比如 acme/user-management 可以对应 "Acme\UserManagement\": "src/"，但不能写成 "Acme\User-Management\": "src/"（PHP 命名空间不允许短横线）。
