# 钩子挂了但逻辑没跑？从一次“发帖后积分不增加”排查生命周期注册时机
把钩子挂上去，代码也写了，日志却干干净净——这是插件开发里很常见的一种沉默失败。它不像报错那样给你堆栈，也不像白屏那样明显，只是“什么都没发生”。最近帮一位开发者排查“发帖后积分不增加”的问题，最后发现根因不在积分逻辑，而在钩子的注册时机：代码挂在了生命周期已经开始之后。
这篇不重复讲“钩子怎么挂”的入门步骤，而是聚焦一个更容易被忽略的问题：什么时候挂，和挂在哪个钩子上，同样重要。
先确认一件事：钩子到底有没有被调用
排查沉默失败，第一步不是读积分代码，而是确认钩子有没有进。最省事的办法是在钩子处理函数的第一行写一条临时日志：
function my_plugin_post_create($post) {
error_log('hook fired: ' . __FUNCTION__);
// 原来的积分逻辑
}如果日志没出现，说明问题在注册阶段，积分代码根本轮不到执行。如果日志出现了但积分没加，才需要往业务逻辑里查。这一步能把“钩子没触发”和“钩子触发了但逻辑错”彻底分开，省掉大量无效阅读。
注册时机：三种常见错位
第一种，插件入口文件在框架初始化之后才被加载。 很多系统的插件加载顺序是：核心启动 → 读取插件列表 → 逐个 include 插件入口。如果你的注册代码写在入口文件的顶层，而该入口又依赖某个更晚才初始化的对象，注册就会静默失败或被跳过。判断方法：在入口文件顶部打一条日志，看它出现的顺序是否早于目标钩子的触发点。
第二种，把注册写进了某个“只在特定请求才执行”的分支。 比如只在后台请求里注册，前台发帖时自然不生效。这类问题在调试时容易被忽略，因为后台测试一切正常。
第三种，钩子名称拼写或参数个数不匹配。 有些框架对钩子名大小写敏感，有些会在参数数量不符时直接跳过而不报错。把钩子名复制到全局搜索里比对一遍，比凭记忆手写可靠得多。
调试顺序：从外到内，而不是从内到外
一个可复用的排查顺序是：
- 确认插件已被系统识别（插件列表里状态正常）；
- 确认入口文件被执行（顶部日志）；
- 确认注册语句被执行（注册前后各一条日志）；
- 确认钩子被触发（处理函数首行日志）；
- 最后才查业务逻辑。
这个顺序的价值在于：每一步都只回答一个是非题，不会在多层调用里迷路。很多人一上来就单步调试积分计算，结果发现钩子压根没进，时间全花在了错误的方向上。
一个容易踩的细节：注册与触发的先后关系
生命周期钩子的本质是“在某个时间点广播一个事件”。如果注册发生在广播之后，这次广播就与你无关。所以判断注册时机是否安全，可以问自己一句：这段注册代码执行时，目标事件发生了没有？ 对于“发帖后”这类事件，注册必须发生在发帖动作之前，通常也就是插件初始化阶段。把注册逻辑挪到初始化入口，而不是散落在各个业务分支里，能规避大部分时机问题。
结语
钩子调试的难点往往不在钩子本身，而在“它没跑”这件事没有任何提示。把“确认有没有被调用”作为固定第一步，再按从外到内的顺序推进，沉默失败就会变得可定位。你在挂生命周期钩子时，遇到过哪种最隐蔽的“不触发”？是加载顺序、条件分支，还是命名问题？
