从零开始搭一个能下断点的插件骨架：我的本地调试环境配置与最小可运行目录结构

第一次写插件的时候，我直接把代码往 wp-content/plugins 里一丢，改一点刷新一下页面，报错就 var_dump 到处插。三天之后，我得到了一个满是 die() 尸体的代码库和一颗想重装 WordPress 的心。后来才意识到，插件的目录结构和入口文件设计，本质上是在回答一个问题：怎么让调试器能精准地停在你想停的地方，而不是在 WordPress 核心里迷路。

我的目录结构：不是"规范"，是"能调试"

我见过很多"最佳实践"把目录拆得特别细，但新手阶段我更倾向于按"调试边界"来切分。这是我的最小可运行骨架：

my-plugin/
├── my-plugin.php          # 入口文件：只做"插件身份声明"和"引导启动"
├── bootstrap.php          # 实际初始化：类加载、常量、容器绑定
├── src/
│   ├── Admin/             # 后台相关：页面、AJAX、设置
│   │   └── SettingsPage.php
│   ├── Frontend/          # 前台相关：短码、模板干预
│   ├── Core/              # 跨层工具：数据库抽象、HTTP客户端封装
│   └── Contracts/         # 接口定义：方便后面写单元测试时 mock
├── assets/
│   ├── js/                # 源码，未经构建
│   └── css/
├── build/                 # 构建产物（如果有 webpack/vite）
├── tests/                 # 不是"以后再说"，是现在就建
│   └── bootstrap.php      # 测试环境自己的引导文件
└── .vscode/               # 调试配置，随仓库走
    └── launch.json

关键决策：入口文件 my-plugin.php 里不写业务逻辑。WordPress 的插件头注释必须在这个文件顶部，但类实例化、钩子挂载全挪到 bootstrap.php。这样 PHPStorm 或 VS Code 下断点时，你不会在插件头和 namespace 声明之间反复横跳。

入口文件的"防坑"写法

很多教程的入口文件长这样：

run();

问题在哪？直接执行。如果 MyPlugin 的构造函数里抛异常，WordPress 的插件启用流程会被打断，但错误信息可能吞在 register_activation_hook 的上下文里，你看到的是"插件已启用"或者一个白屏。

我现在的入口文件：

%s