composer 默认不将插件装入 wp-content/plugins，因其仅管理 vendor/ 下的 php 包 autoload 和依赖，需配合 composer/installers 及正确 type 声明和 installer-paths 配置实现映射。
Composer 不能直接管理 WordPress 插件的运行时行为，但可以可靠地管理插件的源码分发、版本锁定和依赖安装——前提是插件本身支持 Composer 安装（即提供 composer.json 并发布到 Packagist 或私有仓库）。
为什么默认 install 命令不把插件放进 wp-content/plugins
Composer 的默认安装路径是 vendor/，它只管 PHP 包的 autoload 和依赖解析，不关心 WordPress 的目录结构约定。直接运行 composer require wpackagist-plugin/akismet 后，插件代码会落在 vendor/wpackagist-plugin/akismet，WordPress 根本不会加载它。
解决思路不是改 Composer 行为，而是用插件或配置把 vendor 里的包“映射”进 WordPress 的插件目录：
- 使用
wpackagist.org镜像源（如wpackagist-plugin/akismet）时，必须配合composer/installers插件，并在composer.json中声明"type": "wordpress-plugin" - 确保根项目
composer.json包含："extra": { "installer-paths": { "wp-content/plugins/{$name}/": ["type:wordpress-plugin"], "wp-content/themes/{$name}/": ["type:wordpress-theme"] } } - 若插件未声明
type（比如作者没配），即使你手动加"type": "wordpress-plugin"到 require 块也没用——Composer 不识别该包的类型，不会触发 installer-path 规则
如何让私有插件也走 Composer 流程
如果你自己开发插件并希望纳入 Composer 管理，关键不是“怎么打包”，而是“怎么声明”。不需要上传到 Packagist，本地或 Git 仓库即可：
- 插件根目录放
composer.json，内容至少包含：{ "name": "myorg/my-cool-plugin", "type": "wordpress-plugin", "autoload": { "psr-4": {"MyCoolPlugin\": "src/"} } } - 主项目
composer.json加仓库配置："repositories": [ { "type": "vcs", "url": "https://git.example.com/myorg/my-cool-plugin.git" } ] - 然后
composer require myorg/my-cool-plugin即可按installer-paths规则自动落到wp-content/plugins/my-cool-plugin/ - 注意：Git 仓库的默认分支必须是
main或master，否则需指定"dev-main"版本约束
composer update 会不会覆盖已激活插件的设置
不会。Composer 只替换文件，不触碰数据库。WordPress 插件的设置（options、posts、usermeta 等）全存在数据库里，和文件更新无关。但有两个例外要手动处理：
- 插件升级含数据库迁移（如新增表、修改字段），需插件自身提供
register_activation_hook或wp_update_plugins钩子逻辑，Composer 不参与 - 如果插件用了
wp-content/plugins/my-plugin/config.php这类硬编码配置文件，而你用 Composer 覆盖了整个目录，配置就丢了——应把敏感配置移到wp-config.php或环境变量中
真正容易被忽略的是：Composer 管理插件的前提，是你对整个 WordPress 核心+主题+插件的部署流程做了统一设计。比如，wp-content 目录是否纳入 Git？vendor 是否排除？wp-config.php 怎么处理？这些决策比“能不能用 Composer”影响更大。
