路由、评论和 API 怎么啃？先抓住这三条链路

如果说前面的主题、插件、Hook、Metas 还算是一条线往前学，那从这一篇开始，很多人会明显感觉：

难度上来了。

最容易把人绊住的三块，通常就是：

• 路由
• 评论
• API

这三块的共同点是，它们都不是单纯的“改个模板”。

你如果还拿“页面结构思维”去处理，通常会越改越乱。

更稳的方式，是分别抓住它们各自的链路。

一、先说路由：它不是页面长什么样，而是 URL 怎么进系统

很多人一听路由，就容易立刻想到前端框架。

但在 Z-BlogPHP 里，路由首先解决的是：

• 某个 URL 怎么被识别
• 某类请求交给谁处理
• 自定义页面怎么接进系统

常见的现代做法，是通过：

• Filter_Plugin_Zbp_PreLoad
• $zbp->RegRoute(...)

来注册路由。

也就是说，路由工作通常不是在模板里开始的，而是在更早的请求阶段开始的。

二、什么时候你真的需要自己注册路由

不是所有页面都要自定义路由。

更适合用路由的，通常是这些场景：

• 自定义专题页 URL
• 自定义工具页 URL
• 特殊下载页
• 搜索重写
• 需要独立匹配规则的扩展页面

如果只是普通首页、分类页、文章页，其实大多已经有现成流程。

不要为了“感觉高级”把能用现成模板解决的东西硬改成自定义路由。

三、注册路由时，你最该先看哪几个字段

一个路由定义里，常见会看到这些信息：

• posttype
• type
• name
• call
• urlrule
• args

你不用一开始把所有键都背下来。

先抓住最核心的三个问题：

1. 这个路由匹配什么 URL
2. 匹配后调哪个处理函数
3. 处理函数能拿到哪些参数

这三件事先想明白，已经能做很多实际开发了。

四、路由处理函数最重要的意识：它拿到的是匹配结果

路由不是纯页面模板。

它更像是：

• URL 先被规则匹配
• 提取出参数
• 再进入处理函数

所以你在处理函数里最先要做的，不是急着输出 HTML，而是先看：

• 传进来的参数长什么样
• 当前请求想干什么
• 最终要不要交给模板、对象、重定向或其他逻辑

这也是为什么路由问题更接近“请求链路”，不只是“页面结构”。

五、再说评论：真正难的不是列表，是提交链路

很多人一开始看评论，以为评论开发主要是：

• 评论列表长什么样
• 回复按钮放哪里
• 表单长什么样

这些当然重要，但真正最容易出问题的地方，其实是提交链路。

一个评论提交的典型顺序，大致是：

1. 前台表单发起提交
2. 请求进入评论处理流程
3. 平台做基本校验
4. 插件 Hook 可能介入
5. 评论被通过、审核或拒绝
6. 前台拿到成功或错误反馈

只要你开始理解这是一条链路，评论问题就容易拆开看。

六、评论问题到底先看模板还是先看 Hook

答案是：看你改的是什么。

更像模板问题的

• 评论列表展示错位
• 回复结构错乱
• 表单字段排版问题
• 评论区位置不对

这种先看：

• comments.php
• single.php

更像流程问题的

• 评论提交失败
• 提交后被错误拦截
• 审核状态不对
• 反垃圾误判
• Ajax 和普通提交表现不一致

这种先看：

• Filter_Plugin_PostComment_Core
• Filter_Plugin_CheckComment_Core
• Filter_Plugin_Error_Handler

很多人评论问题排不出来，就是因为它明明是流程问题，却只盯着模板。

七、评论调试时，最稳的排查顺序

我更建议你按这条线来：

1. 先看评论表单

确认：

• 提交地址对不对
• 必填字段对不对
• 有没有 Ajax 截获

2. 再看平台校验

确认：

• 验证码
• 频率限制
• 基础校验

3. 再看插件 Hook

确认：

• 有没有反垃圾插件
• 有没有审核规则
• 有没有把错误转成自定义提示

4. 最后看前台反馈

确认：

• 提交失败时，前台到底收到了什么
• 是后端真失败，还是前端解析错了

这个顺序会比“到处猜”有效很多。

八、再看 API：它和普通页面是另一条路

很多人刚接触 Z-BlogPHP API 时，会下意识把它和前台页面混在一起理解。

其实它们的重点不一样。

前台页面更关心：

• 模板
• 布局
• 渲染

API 更关心：

• 模块
• 动作
• 权限
• 字段
• 返回结果

原生 API 的入口通常是：

zb_system/api.php?mod=<module>&act=<action>

这个模式一旦理解了，后面很多工具化工作都会顺手很多。

九、原生 API 先看什么，不要一上来就自定义

很多需求其实原生模块已经覆盖不少了。

高频模块包括：

• post
• comment
• member
• category
• tag
• upload
• module
• app
• system

如果你要做的是：

• 文章管理工具
• 评论审核工具
• 分类同步
• 上传管理
• 主题或插件状态切换

先看原生 API，通常比自己再造一套更稳。

十、什么时候才该考虑自定义 API

更适合自定义 API 的，通常是：

• 原生模块覆盖不了
• 你需要一套项目专属接口
• 你要做插件级接口扩展
• 你要把多个原子操作组合成自己的业务动作

这时候常见思路是：

1. 做插件
2. 注册新 API 模块
3. 定义自己的处理函数

如果只是现成模块已经能做的事情，不必为了“统一风格”全部重造。

十一、ApiExecute(...) 为什么值得记一下

很多人一想到 API，就立刻想到 HTTP 请求。

但在 Z-BlogPHP 里，还有一个很实用的思路：

在 PHP 内部直接复用 API 行为。

这时常见会用到：

$result = ApiExecute('post', 'get', array('id' => 2));

它的意义是：

• 不走外部 HTTP
• 直接在内部重用 API 能力
• 适合插件或内部工具调用

这对做站内工具很有价值。

十二、这三块最容易踩的坑分别是什么

路由的坑

• 把模板问题误当成路由问题
• 还没想清 URL 设计就先注册规则
• 只写匹配，不看处理函数拿到什么参数

评论的坑

• 只改评论模板，不看提交流程
• 只看前端报错，不查后端 Hook
• Ajax 和普通提交只测一种

API 的坑

• 不先看原生模块，直接自定义
• 忽略权限和鉴权
• 不核对字段名和动作语义

十三、如果你现在就要动手，建议按这个顺序练

第一步

先做一个简单自定义路由页面。

第二步

再完整走一遍评论提交流程排查。

第三步

最后用原生 API 做一个简单的文章或分类读取工具。

这样你会非常清楚：

• 路由在请求开始前
• 评论是提交流程
• API 是另一条程序入口

结语

路由、评论和 API 难，不是因为它们神秘，而是因为它们都比普通模板更靠近“流程”。

你只要先抓住各自的主线：

• 路由看 URL 怎么进系统
• 评论看提交怎么流转
• API 看模块、动作和权限

后面再进细节时，心里就不会乱。

下一篇我们把这整个系列收住，讲一个真正能上线的 Z-BlogPHP 项目，最后到底该检查哪些东西。