不能直接用——WordPress插件不自动加载vendor/autoload.php，需在主文件头部用__DIR__显式引入并加存在性判断，且须置于插件头注释后、任何类调用前。
composer autoload 在 WordPress 插件里能直接用吗？
不能直接用——WordPress 插件传统结构不触发 vendor/autoload.php，哪怕你 composer install 成功了，new SomeClass() 依然报 Class not found。根本原因是：WordPress 不管你 composer 装了啥，它只按自己的规则加载 PHP 文件（比如 plugins/my-plugin/my-plugin.php 入口被 `require_once` 进来，其余全靠你手动 `include` 或注册 autoloader）。
怎么让插件入口文件主动加载 composer 自动加载器？
最稳妥的做法，是在插件主文件（即带 Plugin Name 注释头的那个 PHP 文件）顶部，显式引入 vendor/autoload.php，并确保路径可靠：
- 用
__DIR__拼路径，别用相对路径如./vendor/autoload.php，避免因当前工作目录变化导致失败 - 加存在性判断，防止开发环境没装依赖时白屏：
if (file_exists(__DIR__ . '/vendor/autoload.php')) { require_once __DIR__ . '/vendor/autoload.php'; } - 放在插件头注释之后、任何类实例化或钩子注册之前，否则类还没加载就调用了
为什么有些插件 autoload 失效？常见坑有哪些？
失效往往不是 composer 配置问题，而是 WordPress 加载时机或路径错位：
word报告自动生成神器
下载
Word报告自动生成神器。自动生成专业Word文档报告，支持模板填充、目录生成、表格/图表插入、页眉页脚、多级标题、样式主题、批量邮件合并。当用户需要生成Word报告、创建合同文档、批量生成通知/证书、填充Word模板、制作商业计划书时触发。
-
autoload.php被引入时，__DIR__指向的是插件主文件所在目录，但如果你把vendor放在子目录（如src/vendor），路径就错了 - 插件被 symlink 到
wp-content/plugins/（比如用npm link或 IDE 调试），__DIR__仍指向真实路径，没问题；但若误用dirname(__FILE__)+realpath()反而可能绕过 symlink，导致路径错乱 - WP-CLI 命令或 REST API 请求中，如果插件未激活，主文件根本不会执行，autoloader 自然不会加载——这不是 bug，是 WordPress 的设计约束
- 使用
"psr-4"映射时，注意命名空间末尾是否多写了反斜杠（如"MyPlugin\": "src/"正确，"MyPlugin\\"错误），会导致类文件找不到
兼容老式 include 结构时，autoload 和手动 require 能混用吗？
能，但必须小心顺序和作用域：
- autoload 是运行时按需加载，
require_once是立即加载；混用时，如果手动require_once 'some-class.php'在 autoload 之前，且该文件里有class SomeClass，那后续通过命名空间 new 实例时，PHP 会报 “Cannot declare class XXX, because the name is already in use” - 建议策略：统一走 autoload，把旧的
include全删掉，用 PSR-4 映射覆盖原有目录结构（比如"MyPlugin\": "includes/"），然后把includes/class-xxx.php里的命名空间补全 - 如果必须保留部分手动加载（例如兼容极老 PHP 版本或动态文件名），确保这些文件不声明已被 autoload 管理的类名
真正麻烦的从来不是写几行 autoload 引入代码，而是当插件被别人当作依赖包引用、或集成进 mu-plugin、或在 WP-CLI 环境下跑单元测试时，那些隐含的加载上下文差异——这时候 __DIR__ 是否可靠、vendor 目录是否随分发一起打包、甚至 ZIP 打包工具会不会漏掉空 vendor/composer 目录，都得一个个盯住。
