ThinkPHP分页进阶：GET与POST请求在分页中的参数处理差异-ThinkPHP-PHP中文网

分页必须用get，因thinkphp分页组件依赖$_get解析页码参数，post会导致分页失效；带搜索的场景需手动合并post业务参数到get链接，页码始终由get控制。

thinkphp分页进阶：get与post请求在分页中的参数处理差异

分页时用 GET 还是 POST，不是风格问题，而是参数能否被正确读取、URL 是否可分享、刷新是否重复提交的实操分界线。

ThinkPHP 的 paginate() 默认生成的分页 HTML 是基于 GET 的：页码、每页条数、搜索关键词等全拼在 URL 查询字符串里，例如 /user/list?page=3&size=10&keyword=admin。这是浏览器前进/后退、书签收藏、SEO 抓取的基础前提。

如果你强行把分页表单设为 method="post"，点击页码会触发 POST 提交，但分页组件本身不处理 POST 参数——$_POST['page'] 不会被自动识别为分页偏移量
手动改写分页 HTML 为 POST 表单，会导致每次跳页都需 JS 拦截并重发请求，丧失原生链接语义，且无法右键“在新标签页打开”
ThinkPHP 的 Page 或 LengthAwarePaginator（5.x/6.x）底层依赖 $_GET 解析 page 和 list_rows，改用 POST 后这些值为空，分页直接失效

常见场景：带搜索表单（method="post"）提交后进入结果页，结果页要分页。此时搜索条件在 $_POST 里，但分页链接仍需 GET —— 你得把 POST 数据转成查询参数附在分页链接上。

ThinkPHP5.1企业站点快速开发

下载

不能直接用 $list->render()，它只读 $_GET，对 $_POST 里的 keyword、status 等一无所知
正确做法是：在控制器中手动构建分页参数数组，例如 $params = array_merge($_GET, $_POST)，再传给分页对象的 appends() 方法（6.x）或 setConfig('var_page', 'page') 配合手动拼参（5.x）
注意同名键覆盖：$_POST['page'] 若存在，会覆盖 $_GET['page']，导致当前页码错乱；建议只合并业务参数，页码始终由 GET 控制

有人图省事用 $_REQUEST['page'] 试图兼容两种请求方式，这在 ThinkPHP 分页中是危险操作。

$_REQUEST 默认包含 $_GET、$_POST、$_COOKIE，顺序由 php.ini 中的 request_order 决定，不同环境行为不一致
ThinkPHP 自身的路由和分页逻辑不依赖 $_REQUEST，它明确检查 $_GET；你用 $_REQUEST 取值，可能拿到过期的 cookie 值或错误的 POST 覆盖
性能上，$_REQUEST 是运行时合并，比直接读 $_GET 多一次数组合并开销，虽小但无必要

用户在 POST 搜索结果页点刷新，浏览器弹出“重新提交表单？”提示——这不是 UI 问题，是 HTTP 协议层对非幂等操作的保护。一旦用户误点“重新提交”，可能重复执行搜索逻辑（比如触发日志记录、调用第三方 API），甚至引发数据异常。

而 GET 分页刷新，只是重发一次查询请求，无副作用，符合 RESTful 原则
若业务强制要求 POST（如含大量过滤字段超出 URL 长度限制），必须用 PRG 模式（Post-Redirect-Get）：POST 提交后 redirect() 到带完整查询参数的 GET 地址，后续分页全部走 GET
别指望前端 localStorage 存 POST 数据来“恢复”，那和服务器状态脱节，分页总数、当前页码都可能错位

最易被忽略的一点：分页组件渲染出的链接，其 href 属性永远只认 GET 参数。哪怕你在 form 里写了 method="post"，只要分页 HTML 是标准 a 标签，点击就发 GET —— 如果没提前把搜索条件 append 进去，点第二页就丢光所有筛选条件。