答案：composer报“package not found”是因为默认只查packagist.org，未配置wpackagist.org仓库；需在composer.json中添加type为composer、url为"https://wpackagist.org"的repositories项，并确保包名格式为wpackagist-plugin/{slug}，同时配置installer-paths将插件正确映射至wp-content/plugins/目录。
composer require wpackagist-plugin/xxx 为什么报“Package not found”
不是插件名写错，是 Composer 根本没去 wpackagist.org 查。它默认只认 packagist.org，必须手动告诉它“去哪找”。
- 在项目根目录的
composer.json中添加repositories配置，type必须为composer（不能是vcs或package） -
url必须完整写成"https://wpackagist.org"，少个s或协议错误都会失败 - 包名严格按
wpackagist-plugin/{slug}格式，比如classic-editor插件对应wpackagist-plugin/classic-editor，slug 来自插件页面 URL 最后一段，别手写拼凑
插件装进 vendor/ 但 WordPress 后台看不到
路径没映射对，文件落错了位置。Composer 默认把所有包扔进 vendor/，而 WordPress 只扫描 wp-content/plugins/ 下的 PHP 文件。
- 先运行
composer require composer/installers:^2.0——这是必需依赖，不是可选项 - 在
composer.json的extra段里加installer-paths，例如："wp-content/plugins/{$name}/": ["type:wordpress-plugin"] - 确保你要安装的插件包自身
composer.json里有"type": "wordpress-plugin"（WPackagist 自动生成的包都有，私有包容易漏） - 执行
composer install -v，看日志是否出现WordPressInstaller::install—— 没这行说明映射根本没触发
主题或插件装进正确目录后仍不显示
文件落地只是第一步，WordPress 还要能读、能识别、能激活。
-
wp-content/plugins/或wp-content/themes/目录必须真实存在，且 Web 进程用户（如www-data）有读取权限（至少755） - 插件主文件（如
akismet.php）必须含标准插件头注释，否则 WordPress 不当它是插件；主题style.css也得有合法的Theme Name:字段 - Composer 不负责激活，装完得用
wp plugin activate akismet（WP-CLI）或后台手动启用 - 如果用了 Bedrock 结构，路径不是
wp-content/plugins/，而是web/app/plugins/，installer-paths必须同步改掉
本地开发引入 Guzzle 或 Monolog 等第三方库时常见坑
这类依赖不是给 WordPress 运行时用的，而是你插件/主题代码里调用的，加载时机和方式必须隔离清楚。
-
composer.json放在插件/主题根目录没问题，但autoload段必须设psr-4并指向src/这类子目录，不能直接映射到根目录 - 在插件主文件开头加判断再引入：
if ( file_exists( __DIR__ . '/vendor/autoload.php' ) ) { require_once __DIR__ . '/vendor/autoload.php'; } - 别在
functions.php或插件激活钩子里require类文件——先让vendor/autoload.php加载好，再use类名 - 提交
composer.lock，但vendor/是否提交取决于分发方式：开源插件建议不提交，打包发布前用composer install --no-dev --classmap-authoritative生成扁平化类映射
type、包 type、路径模板里的 {$name}、Web 用户权限、插件头注释格式——漏一个，整个链路就断在某个静默环节。
