Composer不支持中文包名或路径，所谓“中文工作流”是在英文约束下提升可读性：用行尾中文注释、comments字段说明、CI/CD中文日志及中文文档，但require和installer-paths必须严格使用英文命名与路径。

Composer 本身不支持中文包名、路径或配置字段，任何试图写 wpackagist-plugin/高级自定义字段 或 "wp-content/plugins/微信登录/" 的操作都会直接报错——这不是兼容性问题，是底层解析规则硬性拒绝。所谓“中文工作流”，本质是在英文约束下，让中文团队协作更顺、排查更快、文档更易懂。

怎么让 composer.json 对中文开发者更友好

不改字段值，但可增强可读性和上下文提示：

• composer.json 的 require 字段必须用英文包名（如 "wpackagist-plugin/advanced-custom-fields"），但可以在行尾加中文注释："wpackagist-plugin/advanced-custom-fields": "^6.4" // 高级自定义字段（ACF）
• 利用 comments 字段（非标准但被 VS Code / PHPStorm 识别）集中写说明："comments": "插件映射表：woocommerce → 电商系统；wp-mail-smtp → 邮件服务（替代PHP mail）"
• 避免在 extra.installer-paths 中使用中文路径（如 "wp-content/plugins/微信登录/"），Linux 文件系统编码和 Web 服务器权限容易导致解压失败或 403 错误

为什么插件装进目录却在 WordPress 后台看不到

这是中文用户最常卡住的环节，根本原因不是语言，而是路径激活逻辑被忽略：

WordPress API Pro

生产级WordPress REST API集成，用于管理文章、页面、媒体、WooCommerce产品、Elementor内容、SEO元数据、ACF及JetEngine字段

下载

• 确认 wp-content/plugins/{$name}/ 目录真实存在，且 Web 进程用户（如 www-data）对该目录有 r-x 权限（至少 755）
• 检查插件主文件（如 wp-content/plugins/advanced-custom-fields/acf.php）是否含标准插件头注释，缺 Plugin Name: 行会导致 WordPress 完全跳过扫描
• 运行 wp plugin list --status=active（需 WP-CLI）验证是否已启用；仅靠 Composer 落盘 ≠ 自动激活
• 如果用了 Bedrock 结构，installer-paths 必须对应 web/app/plugins/{$name}/，而非默认路径

怎么让 CI/CD 日志对中文团队更直观

命令本身必须保持英文，但输出信息可本地化，不影响执行逻辑：

• Shell 脚本中用 echo "✅ 正在安装「联系表单 7」插件"，实际执行仍是 composer require wpackagist-plugin/contact-form-7
• GitHub Actions 或 GitLab CI 的 steps.name 字段支持中文，比如 name: "? 安装 WordPress 插件"，界面可读性提升明显
• 错误日志里保留原始英文报错（如 Invalid package name），再追加一行中文解释：# ❌ 包名含中文或特殊字符，请检查是否用了「微信登录」而非「wechat-login」

真正容易被忽略的是：所有“中文友好”措施都建立在严格遵循英文命名规范的前提下。一旦尝试绕过 name 校验、硬塞中文路径或修改 installer-paths 模板语法，Composer 就会立即终止流程——它不报错模糊，而是直接拒绝解析。这种刚性不是缺陷，恰恰是跨团队协作的底线保障。