分页必须用GET，因ThinkPHP分页组件依赖$_GET解析页码参数，POST会导致分页失效；带搜索的场景需手动合并POST业务参数到GET链接，页码始终由GET控制。
分页时用 GET 还是 POST，不是风格问题，而是参数能否被正确读取、URL 是否可分享、刷新是否重复提交的实操分界线。
分页链接生成必须用 GET，否则无法携带页码参数
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 后这些值为空，分页直接失效
POST 请求中做分页，必须显式合并查询条件到 URL
常见场景：带搜索表单（method="post"）提交后进入结果页，结果页要分页。此时搜索条件在 $_POST 里，但分页链接仍需 GET —— 你得把 POST 数据转成查询参数附在分页链接上。
- 不能直接用
$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 控制
$_GET 和 $_POST 混用时，$_REQUEST 不可靠且慢
有人图省事用 $_REQUEST['page'] 试图兼容两种请求方式，这在 ThinkPHP 分页中是危险操作。
立即学习“PHP免费学习笔记（深入）”；
-
$_REQUEST默认包含$_GET、$_POST、$_COOKIE，顺序由php.ini中的request_order决定，不同环境行为不一致 - ThinkPHP 自身的路由和分页逻辑不依赖
$_REQUEST，它明确检查$_GET；你用$_REQUEST取值，可能拿到过期的 cookie 值或错误的 POST 覆盖 - 性能上，
$_REQUEST是运行时合并，比直接读$_GET多一次数组合并开销，虽小但无必要
刷新页面时 POST 分页会中断，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 进去，点第二页就丢光所有筛选条件。
