在WordPress项目开发中如何正确使用Composer？（最佳实践）

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或类文件。安全做法：

标签： php word js 前端 json ajax composer apache wordpress nginx 工具