WordPress主题不能直接在主题目录用composer install，因WP不自动加载vendor/autoload.php；正确做法是将依赖统一放在WP根目录vendor中，主题通过ABSPATH.'/vendor/autoload.php'引入。

WordPress 主题里不能直接用 composer install 加载依赖到 wp-content/themes/your-theme/ 下并指望它自动生效——因为 WordPress 不会自动加载 Composer 生成的 vendor/autoload.php，也不会扫描主题目录下的 vendor 执行 PSR-4 自动加载。

为什么主题根目录放 composer.json 大概率不工作

常见错误是：在主题目录执行 composer require monolog/monolog，然后在 functions.php 里写 require_once 'vendor/autoload.php'; —— 这看似合理，但实际会出问题：

• 主题可能被 ZIP 打包上传，而 vendor 目录默认被 WordPress 忽略（不在白名单内），上传后丢失
• 不同环境（本地 / staging / production）vendor 内容可能不一致，导致行为差异
• 主题更新时若覆盖整个目录，vendor 被清空，站点直接报错
• WordPress 的 wp-content 权限策略常禁止运行 composer 命令，线上无法执行 install

正确做法：把依赖移到主题外，统一由根目录 Composer 管理

核心思路是让主题只负责「使用」，不负责「安装」。所有第三方库统一放在 WordPress 根目录的 vendor，主题通过相对路径加载 autoload。

• 在 WordPress 根目录（即包含 wp-load.php 的同级）执行 composer init 并添加所需包，例如：composer require guzzlehttp/guzzle symfony/http-foundation
• 确保根目录 composer.json 中 "autoload": {"psr-4": {"MyTheme\": "wp-content/themes/mytheme/src/"}}（可选，用于主题内自己的类）
• 在主题的 functions.php 开头加入：

  if (file_exists(ABSPATH . '/vendor/autoload.php')) {
      require_once ABSPATH . '/vendor/autoload.php';
  }

• 之后你就可以在主题中安全使用 new GuzzleHttpClient() 或 new SymfonyComponentHttpFoundationRequest()

插件扩展场景下，用 composer/installers 控制安装路径

如果你开发的是可分发的 WordPress 插件（不是私有主题），又想用 Composer 管理其依赖，必须显式指定安装位置，否则默认装进根 vendor，和主题冲突。

Expanso json-flatten

通过 CLI 或 MCP 服务器，使用 Expanso Edge 管道扁平化嵌套 JSON 对象。

下载

• 在插件项目根目录（非 WP 根目录）运行：composer init，然后执行：composer require composer/installers
• 编辑 composer.json，加入：

  "type": "wordpress-plugin",
  "require": {
      "composer/installers": "^2.0"
  }

• 这样执行 composer require phpmailer/phpmailer 后，包会被装进插件目录下的 vendor/，而不是全局 vendor
• 插件主文件开头加：

  if (file_exists(__DIR__ . '/vendor/autoload.php')) {
      require_once __DIR__ . '/vendor/autoload.php';
  }

避免 class not found 的关键检查点

即使 autoload 引入成功，仍可能报错。以下三点最常被忽略：

• composer dump-autoload -o 必须执行（尤其改了 autoload 配置后），否则新类不会注册进自动加载映射
• 确认类命名空间与 composer.json 中 psr-4 映射完全一致，末尾斜杠不能少："MyTheme\": "src/" ≠ "MyTheme\": "src"
• 如果用了 require-dev 里的包（如 phpunit/phpunit），生产环境运行时不会安装，必须移入 require

真正麻烦的从来不是命令怎么敲，而是 autoload 加载时机、路径解析上下文、以及 WordPress 请求生命周期里哪一刻该 require —— 这些细节一旦错位，Class 'X' not found 就会反复出现，且错误堆栈还藏得特别深。