yii框架不内置无限滚动，必须用扩展（如kop/yii2-scroll-pager）或手写ajax逻辑；直接改linkpager或加scroll事件易致状态错乱、重复加载、dom冲突，因linkpager服务端渲染且不维护客户端分页状态。
Yii 框架本身不内置无限滚动功能，必须依赖扩展或手写 AJAX 逻辑；直接改 LinkPager 或硬套 jQuery 插件容易导致分页状态错乱、重复加载、DOM 冲突——尤其在 GridView/ListView 中混用时。
为什么不能只改 LinkPager 的 CSS 或加个 scroll 事件？
因为 Yii 的传统分页组件（如 LinkPager）是服务端渲染、全量 HTML 输出的，它不维护“已加载页数”“滚动位置”“是否还有下一页”等客户端状态。你监听 window.onscroll 后手动发请求，但返回的 HTML 片段若没做 DOM 结构对齐（比如漏掉 <tr> 闭合、嵌套层级错位），就会破坏表格结构，导致 <code>GridView 的行高计算异常、排序失效、甚至 JS 报错 Cannot read property 'length' of undefined。
- 服务端返回的是完整分页块（含
<ul class="pagination"></ul>），而无限滚动只需要数据行部分 -
renderPartial()默认仍会输出 layout 和脚本注册代码，除非显式禁用：Yii::$app->view->renderPartial('list-item', ['model' => $item], false) - 未重置
Pagination对象的currentPage和totalCount，会导致后续 AJAX 请求页码错位
用 kop/yii2-scroll-pager 时必须改哪几处配置？
这个扩展本质是把 jQuery Infinite Ajax Scroll 封装进 Yii2 生命周期，但它默认行为和常见布局不匹配，不调就容易“滚到底部没反应”或“反复加载第 2 页”。关键要改三处：
-
'paginationSelector'：必须指向实际存在的分页容器，比如'.grid-view .pagination'，不能写成'.pagination'（太宽泛，可能命中其他组件） -
'triggerOffset'：设为100（像素）比默认10更稳，避免快速滚动时触发过早、内容还没渲染完就发请求 -
'bufferTop'和'bufferBottom'：至少设为50，否则在移动端小屏幕下容易误判触底 - 如果用
ListView，需确保itemView返回的每项都带唯一data-key属性，否则插件无法自动追加新项到正确位置
手写 AJAX 无限滚动时怎么避免重复请求和状态丢失？
核心是把“页码”和“是否还有更多”从服务端响应里抽出来，不依赖 DOM 解析。服务端 action 应返回 JSON，例如：
{
"items": [...],
"nextPage": 3,
"hasMore": true,
"totalCount": 1274
}
客户端用 $.ajax 请求后，更新全局变量 window.nextPage = data.nextPage，并用 data.hasMore 控制是否继续绑定 scroll 事件。容易踩的坑：
- 没加 loading 锁：用户快速滚动多次触发，发出 3 个并发请求，后返回的覆盖先返回的，造成数据跳变
- 没清空
scroll事件监听：每次重新绑定前，要用$window.off('scroll')，否则监听器越积越多 - 滚动位置恢复失效：从详情页返回列表页时，
sessionStorage.getItem('scrollY')存的是进入详情前的位置，但 DOM 高度已因新增内容变化，需用setTimeout(() => window.scrollTo(0, y), 100)延迟执行
真正麻烦的不是滚动触发，而是服务端如何高效提供“下一页”数据——活动记录（ActiveRecord）查询必须用 offset/limit 而非 page 参数，否则当某页数据被删/新增时，会出现漏项或重复。这点在 kop/yii2-scroll-pager 的文档里几乎没提，但线上环境一定会遇到。
