WordPress插件激活检测疑问：为何init钩子内无法监听自身插件激活？

你的观察非常准确——在init钩子里能正常监听其他插件的激活，却对自身插件失效，这完全是WordPress插件激活的执行顺序和重定向机制导致的，我来给你拆解清楚：

1. 自身插件激活的核心流程差异 #

当你激活自己的myplugin.php时，WordPress的执行步骤是这样的：

• 首先，WordPress会先加载你要激活的插件文件（也就是myplugin.php），此时如果插件根文件里直接写了register_activation_hook，这个钩子会被立刻注册。
• 接着，WordPress执行插件激活的核心逻辑，触发你注册的激活回调。
• 激活完成后，WordPress会执行强制重定向（这是关键中的关键！），跳转到插件列表页或者你指定的激活后页面。
• 只有在重定向之后的新请求里，init钩子才会被触发。

而你在init里注册自身插件的激活钩子，这个动作是在激活流程已经完全结束、新请求才执行的，此时激活钩子早就触发过了，自然不会有任何响应。

2. 为什么监听其他插件激活能正常工作？ #

当你激活“Hello Dolly”这类第三方插件时，流程完全不同：

• 你的myplugin.php已经处于激活状态，所以在当前请求的最开始就被加载了，init钩子会按时触发。
• 你在init里注册的register_activation_hook('hello.php', ...)会被WordPress记录下来。
• 紧接着WordPress才会加载并激活“Hello Dolly”，触发它的激活钩子——这时候你的回调已经注册好了，自然能被执行。

3. 关于自定义myplugin_activate钩子的情况 #

你直接在插件根文件里注册激活钩子，并在里面触发自定义myplugin_activate时：

• 激活流程会立刻触发你的激活回调，myplugin_activate钩子也会被即时执行。
• 但如果你把add_action('myplugin_activate', ...)放到init里，同样是因为init在激活流程之后的重定向请求才触发，这个监听动作晚了一步，根本赶不上钩子的触发时机。

核心结论 #

• 自身插件激活：激活动作发生在当前请求的极早期，此时init还没触发，你在init里的任何钩子注册都赶不上激活的时间点。
• 其他插件激活：你的插件已经处于激活状态，init在激活第三方插件之前就触发了，所以注册的激活钩子能被正常执行。

如果你的需求是在插件激活时做拦截或处理，正确的做法是直接在插件根文件里注册激活钩子，不要放到init里。如果需要延迟执行某些逻辑，可以在激活钩子里设置一个临时选项，然后在init里检查这个选项来执行后续操作。

内容的提问来源于stack exchange，提问作者Maxwell s.c