WordPress项目中Composer应严格区分依赖层级：管代码依赖，不混入WP核心和wp-content内容；按纯主题/插件、站点级、Headless三类选择策略；隔离vendor目录防泄露；插件主题通过composer/installers映射管理；锁定精确版本并手动验证。
WordPress项目中使用Composer不是简单地把插件或主题用composer require装进去，而是要分清依赖层级、控制更新边界、避免运行时冲突。核心原则是：Composer管“代码依赖”，WordPress本身和运行时内容（如wp-content下的插件/主题）应尽量不混入vendor目录。
明确项目类型，选择合适的Composer策略
WordPress项目大致分三类，每种对应不同Composer用法：
-
纯主题/插件开发（独立包）：以
composer.json声明自身依赖（如Guzzle、Monolog），用composer install --no-dev生成vendor/，再通过autoload加载；不安装WordPress核心，也不写wp-content路径。 -
站点级项目（含完整WP环境）：用
johnpbloch/wordpress或roots/wordpress作为require项，通过installer-paths将WordPress核心放在web/wp/等子目录；插件/主题用wp-cli或专用插件（如composer/installers+ 自定义type）分离管理。 -
Headless/REST驱动站点：WordPress仅作API后端，前端为独立应用；此时Composer只管理WP核心+必要插件（如
wp-rest-api-controller），PHP依赖与前端解耦，vendor/不暴露给Web根目录。
避免vendor目录被Web服务器直接访问
默认vendor/在项目根目录，若Web根目录（如htdocs或public/）未做隔离，可能泄露composer.lock或类文件。安全做法：
- 将Web入口点设为
public/或web/目录，vendor/、wp/、composer.json全部放在其上级； - 在
public/index.php中显式引入../vendor/autoload.php，不依赖自动发现； - Apache加
Require all denied location ~ ^/vendor/ { return 403; }。
插件与主题的Composer化管理（谨慎启用）
不建议直接composer require wpackagist-plugin/akismet把插件装进vendor/并软链到wp-content/plugins/——这会破坏插件更新机制且易出权限问题。更稳妥方式：
- 用
composer/installers+wpackagist源，配合"type": "wordpress-plugin"，指定installer-paths映射到wp-content/plugins/{$name}/； - 所有插件/主题必须声明
type字段，且composer.json中禁用auto-discover，防止意外加载； - 生产环境部署后执行
wp plugin activate --all（需WP-CLI），而非依赖mu-plugin自动激活。
锁定版本，区分开发与生产依赖
WordPress生态对语义化版本支持不一，很多插件不遵循SemVer。因此：
