Z-BlogPHP 的运行方式到底是什么？先把请求路径想明白
Yojack
6天前
20 浏览
0 评论
很多开发新手学 Z-BlogPHP，最困惑的不是“语法怎么写”，而是：
- 一个页面到底从哪里开始跑
- 为什么有的需求改模板就够了，有的却得进
include.php - 插件 Hook 究竟是在哪个阶段插进来的
- 搜索、评论、文章页、分类页，为什么排查路径总不一样
这篇就做一件事：
把 Z-BlogPHP 从入口到输出的大致运行流程，讲成一张能在脑子里跑起来的路线图。
你不需要一上来就背源码，但一定要先建立整体感。
一、先看站点根目录的几个入口文件
一个标准的 Z-BlogPHP 站点根目录里，最值得先认识的是这几个入口：
index.php
search.php
feed.php
很多人看到这些文件会下意识觉得：
index.php只负责首页search.php只负责搜索结果feed.php只负责订阅输出
这种理解不算错，但还不够。
更重要的是，你要意识到：
它们是请求进入系统的起点。
用户访问某个页面时，请求会先从对应入口进去，然后再逐步进入平台逻辑、主题逻辑和插件逻辑。
所以看懂入口，不是为了改入口本身，而是为了知道问题是从哪条路进来的。
二、运行流程先记成这 7 步
如果先不陷进源码细节，你可以把 Z-BlogPHP 的前台运行过程，粗略理解成这 7 步：
- 浏览器请求某个 URL
- 进入对应入口文件
- 平台层完成初始化
- 当前主题和插件开始参与流程
- 系统判断当前页面类型和数据来源
- 主题模板接手页面结构输出
- 页面最终返回给浏览器
这条顺序很重要。
因为后面你排问题时，基本都绕不开这几个判断：
- 问题出在入口前还是入口后
- 出在平台层还是扩展层
- 出在数据准备阶段还是模板渲染阶段
三、平台层和项目层，要先在脑子里分家
这一点越早分清，后面越不容易乱。
平台层
通常更接近：
zb_system/*- 原生 API
- 路由机制
- Hook 体系
- 系统函数和对象
你可以把它理解成“程序底盘”。
项目层
通常更接近：
zb_users/theme/*zb_users/plugin/*- 上传、缓存、日志
你可以把它理解成“站点自己的功能和外观”。
前台请求进来以后，一开始确实会经过平台层。
但大多数真正属于你业务需求的变更，最后都应该落在项目层。
所以理解运行流程，不是为了鼓励你改核心，而是为了帮你更准确地把需求放回主题和插件。
四、页面渲染时，主题通常在什么时候接手
很多人学主题开发时，会误以为模板文件就是一切。
其实模板是“渲染输出层”，但不是整个流程的全部。
一个典型的前台页面，在主题接手时，往往至少已经发生了这些事：
- 系统完成初始化
- 当前请求被识别为某种页面类型
- 当前文章、分类、标签、列表数据已经有了基本对象
- 当前主题已经被识别
- 当前已启用插件也可能已经在前面某些阶段挂入逻辑
这时候，主题才开始主要负责：
- 页面结构
- 模板拆分
- 元信息输出
- 列表卡片布局
- 详情页内容组织
- 评论区摆放
也就是说，模板更像“最终页面怎么长”，而不是“整套系统怎么跑”。
五、插件和 Hook，是在流程中间插进来的
理解 Z-BlogPHP 的插件，最忌讳把它想成一个完全独立的小程序。
更准确的理解是：
插件通常是借助 Hook，在系统已有流程里的某个阶段插进去。
这也是为什么你经常会看到：
RegisterPlugin("AppID", "ActivePlugin_AppID");
Add_Filter_Plugin('Filter_Plugin_Xxx', 'YourFunction');
它的意思不是“从零造流程”，而是：
- 先注册这个插件
- 再把某段逻辑挂到某个阶段
比如常见阶段就包括：
- 早期加载
- 列表页渲染前后
- 文章页渲染前后
- 评论提交和校验
- 后台菜单和编辑页输出
- API 扩展
所以你后面看到 Hook，不要先问“这个名字难不难记”，而要先问：
这个 Hook 所在的阶段，离我当前想改的行为近不近？
六、你可以把前台请求理解成“数据准备”和“模板输出”两大段
这个拆法很适合排查问题。
第一段：数据准备
这段更接近：
- 当前是什么页面
- 当前对象是谁
- 列表查哪些文章
- 搜索关键字是什么
- 分类、标签、作者、分页参数是什么
如果问题属于下面这些，更可能出在数据准备段：
- 列表不对
- 文章对象不对
- 搜索结果不对
- 分页不对
- 分类页拿错数据
这时候你通常应该先看：
- 页面类型判断
- 主题
include.php - 插件 Hook
- 原生查询和系统流程
第二段：模板输出
这段更接近：
- 页面头部怎么写
- 列表卡片怎么排
- 标题、摘要、图片怎么显示
- 评论区放哪里
- 页脚脚本怎么引
如果问题属于下面这些，更可能出在模板输出段：
- 布局乱了
- 字段显示位置不对
- 模板分支判断不对
- 头部 meta 没输出
- 评论区位置不对
这时候你通常应该先看：
header.phpindex.phpsingle.phpsearch.phpcomments.phpfooter.php
七、为什么有的需求改模板就行，有的必须进 include.php
这是很多人从“会改页面”到“会开发”的分水岭。
更适合改模板的情况
比如：
- 列表卡片布局要调整
- 文章页作者信息位置要变
- 搜索页标题文案要改
- 页脚结构要改
- 评论区展示顺序要调
这些需求更偏“页面怎么显示”，所以模板优先。
更适合进 include.php 的情况
比如：
- 需要统一生成缩略图逻辑
- 需要根据页面类型决定是否加载资源
- 需要新增主题配置项并参与渲染
- 需要把多个模板复用的逻辑抽出来
- 需要在列表渲染前调整某些派生数据
这些需求更偏“页面显示前的逻辑准备”，所以更适合放在主题逻辑层。
更适合用插件的情况
比如：
- 评论反垃圾
- 后台扩展
- 自定义字段注入
- 通用功能模块
- API 对接
- 路由扩展
这些需求不只是某个模板长什么样，而是“系统流程的某个点需要被接管”，所以插件更合适。
八、搜索、评论、API，这三条路和普通页面不完全一样
很多人前面几篇都懂了，一到这三块又开始乱。
搜索
搜索页虽然最终也会走模板渲染，但它通常有自己更明确的请求来源和关键字处理。
所以你排查搜索问题时，不能只盯着列表模板，还要看：
- 搜索入口
- 搜索参数
- 搜索结果模板
评论
评论不只是“显示一个列表”，它还是一条提交链路。
常见顺序通常是：
- 评论表单
- 提交目标
- 平台校验
- 评论 Hook
- 保存、审核或报错
- 前台结果反馈
所以评论问题常常横跨：
- 模板
- 插件
- 平台校验
- 错误处理
API
API 又是另一条路。
它通常不是直接走前台模板，而是走：
zb_system/api.php?mod=<module>&act=<action>
所以 API 的判断重点不是页面长什么样，而是：
- 调哪个模块
- 权限怎么验证
- 请求字段是什么
- 返回结构是什么
九、真正排问题时，最稳的顺序是什么
很多人一出问题就全站搜关键词，这当然也有用，但更稳的是按路径查。
我更建议你按这个顺序来：
1. 先判断这是什么类型的问题
是：
- 普通列表页
- 文章详情页
- 独立页面
- 搜索页
- 评论提交
- 后台设置
- API 请求
问题类型一变，排查路线就会明显不同。
2. 再判断问题更像“数据问题”还是“展示问题”
这一刀切开以后，你就知道先看逻辑层还是模板层。
3. 再找真正拥有这个行为的文件
通常优先看：
- 主题模板
- 主题
include.php - 插件
include.php - 插件
main.php
只有当你确认扩展层看不出头绪，才继续往平台层读。
4. 最后才进核心和系统流程
这是“实在需要”的阶段，不是默认第一步。
十、建议你给自己建立一套请求追踪习惯
后面你写主题、写插件、调评论、调 API，都会越来越依赖这个习惯：
看到一个页面，先问这几件事
- 这是从哪个入口进来的
- 这是哪种页面类型
- 它主要靠哪个模板输出
- 有没有主题逻辑参与
- 有没有插件 Hook 可能插进来
看到一个需求，先问这几件事
- 这是改显示，还是改流程
- 是全站逻辑，还是单页面逻辑
- 是主题职责，还是插件职责
- 有没有原生能力已经能做
只要这套判断熟起来，Z-BlogPHP 的开发难度会下降很多。
结语
Z-BlogPHP 的运行流程，其实没有看起来那么玄。
它最核心的理解就是这几件事：
- 请求先从入口文件进入
- 平台层先做初始化和基础流程
- 主题和插件在合适的阶段接手
- 模板负责最终页面输出
- 评论、搜索、API 会走各自更具体的支线
你不需要一开始就把系统源码全背下来。
但一定要先建立一个能跑通的脑内流程图。
下一篇我们继续把这个理解再推进一步，专门讲 Z-BlogPHP 开发里最重要的一张图：文件职责表。什么需求该落在哪个文件里，这件事一旦想清楚，开发会省掉很多弯路。
发表评论：