分页请求应优先用get，因其支持缓存、书签和幂等性；仅当url超长时才用post并手动管理历史；数据超1000条必须后端分页，推荐游标分页；需加请求锁防重复提交；键盘翻页和跳转输入需事件绑定与焦点管理；游标值须原样透传。
分页请求该用 GET 还是 POST？
GET 是默认且推荐的选择，只要参数能放进 URL 里（比如 page=3&limit=20），就别用 POST。浏览器前进/后退、书签收藏、服务端缓存、CDN 缓存都依赖 URL 的可读性和幂等性。用 POST 分页，刷新页面会弹“重新提交表单”，用户点两次可能重复加载，后端也难做缓存。
- 参数必须是纯查询性质，不含敏感或超长字段（如 base64 图片）
- 如果单页数据量大、字段多（比如带复杂 filter JSON），URL 超过 2048 字符，才考虑改用 POST +
fetch+ 手动管理历史（history.pushState） - 不要因为“POST 看起来更‘正式’”就滥用——HTTP 方法语义比形式重要
前端分页 vs 后端分页，什么时候该切？
真数据超过 1000 条，就必须后端分页。前端分页（一次性拉全量再 JS 切）看似简单，实际会卡死低端设备、拖慢首屏、浪费带宽，而且搜索/排序无法跨页生效。
- 后端分页靠数据库
LIMIT offset, size或游标（cursor-based），推荐游标：避免OFFSET越大越慢的问题 - 前端只保留当前页数据和分页元信息（
total、has_next、next_cursor） - 滚动加载（infinite scroll）本质还是后端分页，只是触发方式从点击变成滚动监听，别混淆概念
点击“下一页”按钮后，如何避免重复请求？
最常见 bug 是用户手快连点两次，导致两个并发请求返回后覆盖渲染，UI 错乱或数据跳变。核心是加请求锁，不是禁用按钮（禁用不解决网络延迟场景）。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 发起请求前检查
isFetching状态，为true直接 return - 请求开始设
isFetching = true，成功/失败后统一设false - 更稳妥的做法：用
AbortController主动中止上一个未完成请求（尤其适合搜索分页，用户输入新关键词时旧请求应丢弃） - 不要用
setTimeout防抖代替状态锁——它掩盖问题，不解决竞态
分页组件怎么支持键盘翻页（← →）和跳转输入？
纯鼠标操作对效率型用户不友好。键盘支持成本低但体验提升明显，重点在事件绑定和焦点管理。
- 绑定
keydown监听ArrowLeft/ArrowRight，调用对应goToPrevPage()/goToNextPage() - 跳转输入框需限制输入范围：
value必须是 1 到Math.ceil(total / limit)的整数，非数字或越界时自动修正或清空 - 输入后回车触发跳转，失焦时也应触发（避免用户点别处忘记提交）
- 注意：跳转后要把焦点移回分页区域（
paginationRef.focus()），否则键盘操作中断
后端游标分页的 next_cursor 值容易被前端忽略或硬编码成字符串拼接，实际它可能是 base64 编码的时间戳+ID 组合，直接当普通参数传会出错。每次翻页都该原样透传，不解析、不修改。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
