wordpress mu插件不支持自动加载composer.json,需手动require vendor/autoload.php;推荐将composer.json和vendor置于mu-plugins/子目录,入口文件用__dir__动态加载,并统一vendor路径避免冲突。

WordPress MU插件不支持composer.json自动加载?
不是不支持,是WordPress本身根本不读MU插件目录里的composer.json——wp-content/mu-plugins/下所有PHP文件都会被无条件include,但Composer的自动加载机制(vendor/autoload.php)不会自动触发。
常见错误现象:Class not found,哪怕vendor/已存在、autoload.php路径也写对了,只要没显式require,类就永远加载不上。
- 必须在MU插件PHP文件顶部手动
require一次vendor/autoload.php - 路径不能写死,得用
__DIR__动态定位,否则换环境就挂 - 别把
vendor/放mu-plugins/里——它会被WordPress当成插件执行,报Parse error或Headers already sent
mu-plugins/目录下怎么组织依赖和自动加载
推荐结构:把MU插件本身当“顶层包”,composer.json放在mu-plugins/my-plugin/内,vendor/也生成在同级;再通过一个入口文件(如my-plugin.php)来加载自动加载器和主逻辑。
使用场景:你有一套自研工具库(比如myorg/utils),想在MU插件里复用,又不想全局安装到WordPress根目录。
-
mu-plugins/my-plugin/composer.json定义依赖,运行composer install --no-dev -
mu-plugins/my-plugin/my-plugin.php开头写:require __DIR__ . '/vendor/autoload.php';
- 这个
my-plugin.php必须是纯PHP文件(无BOM、无输出),且WordPress只认它为MU插件——其他文件(如src/里的类)靠自动加载器加载 - 别用
composer dump-autoload -o优化自动加载,MU插件启动极早,OPcache可能还没就绪,反而增加冷启动失败风险
多个MU插件共用同一套依赖?小心autoload.php重复加载
如果两个MU插件各自带vendor/,又都require自己的autoload.php,会触发Composer的“重复注册”警告,甚至导致类定义冲突(尤其用了classmap或files类型加载时)。
性能影响:每次请求多加载1–2个autoload.php,看似微小,但在高并发下会放大文件I/O和OPcache键冲突。
- 统一依赖方案:把
vendor/提到wp-content/根下(如wp-content/vendor/),所有MU插件都require wp-content/vendor/autoload.php - 确保
wp-content/vendor/不在Web可访问路径下(Nginx/Apache需屏蔽/wp-content/vendor/目录) - 用
composer config vendor-dir "wp-content/vendor"固定路径,避免不同插件各自install出多个vendor/ - 不要用
autoload-files加载全局函数——MU插件加载顺序不可控,函数重定义直接500
为什么wp-cli执行时autoload.php找不到?
WP-CLI默认工作目录是WordPress根目录,而你的MU插件里写的require __DIR__ . '/vendor/autoload.php',在CLI下执行时__DIR__指向的是MU插件目录,路径是对的——但问题常出在权限或符号链接上。
典型错误信息:Warning: require(.../vendor/autoload.php): failed to open stream
- 检查
vendor/是否真的存在,且web服务器与CLI用户(如www-datavsubuntu)都有读取权限 - 如果用了Docker或部署脚本,确认
composer install是在目标环境运行的,不是本地build完拷进去的(权限/UID可能错乱) - 避免用相对路径如
../vendor/autoload.php——MU插件可能被软链到别处,__DIR__才是唯一可靠的锚点 - 调试技巧:在MU插件开头加
error_log('Autoloader path: ' . __DIR__ . '/vendor/autoload.php');,然后wp eval "error_log('hello');"看日志
最麻烦的其实是路径拼接和权限错位,不是技术逻辑有多难。多打一行error_log,比翻三遍文档快。










