Bootstrap Table 原生不支持自动无限滚动，需手动启用：设置 scrollHeight 触发滚动条，监听 onScrollBody 判断到底部，调用 append 或 refreshOptions 加载数据，禁用 pagination 并自行处理 AJAX 请求。
Bootstrap 本身不提供无限滚动加载能力，必须依赖第三方插件或手写逻辑；直接用 Bootstrap Table 或 bootstrap-select 实现时，关键在是否启用虚拟滚动和分页接口配合。
bootstrap-table 的 infinite scroll 怎么启用
bootstrap-table 插件支持 scrollHeight + onScrollBody 手动触发加载，但原生不带“自动无限滚动”开关。真正可行的路径是：
- 设置
height或scrollHeight强制表格容器出现垂直滚动条 - 监听
onScrollBody回调，判断滚动到底部（scrollTop + height >= $tableBody[0].scrollHeight - 10） - 手动调用
$table.bootstrapTable('append', newData)或refreshOptions更新数据 - 务必禁用
pagination，否则会与滚动逻辑冲突
注意：data-url 配置的远程加载默认只走一次，后续滚动必须自己发 AJAX 请求，不能指望插件自动续载。
bootstrap-select 开启 virtualScroll 后仍卡顿怎么办
从 v1.13.0 起 bootstrap-select 支持 virtualScroll: true，但卡顿往往不是因为没开，而是配置或环境问题：
- 未设置
size属性（如size="10"），导致可视区计算失效，全部选项仍被渲染 - 原始
<select></select>里含大量<option></option>标签（尤其带 HTML 内容），初始化阶段仍会遍历解析，应改用data-live-search="false"+data-actions-box="false"减负 - 服务端未做分页，每次请求返回全量数据，前端虚拟滚动失去意义——必须配合
offset/limit参数做服务端分页 - Chrome DevTools 中检查
Performance面板，常见瓶颈是频繁触发layout，建议给父容器加contain: layoutCSS 规则
无限滚动 vs 传统分页：哪些场景不该用无限滚动
无限滚动不是银弹，尤其在 Bootstrap 生态中容易掩盖真实问题：
- 用户需要跳转到特定页码（如“查看第 47 页订单”），无限滚动无法满足，
bootstrap-table的pageNumber和pageSize就失效了 - SEO 不友好：搜索引擎爬虫通常不执行滚动行为，动态加载的内容大概率不被索引
- 页脚不可达——如果页面底部有
<footer></footer>或重要操作按钮（如“导出全部”），无限滚动会让它永远被新数据顶出视图 - 内存泄漏风险：某些 bootstrap-select 版本在反复销毁/重建时未清理事件监听器，
$(select).selectpicker('destroy')后需手动清空$.data
服务端分页接口怎么和前端对齐
前端无限滚动能否稳定运行，极度依赖后端接口设计是否合理：
- 必须返回
total字段（哪怕估算值），否则前端无法判断“是否到底” - 推荐使用游标式分页（
cursor）而非page/limit，避免高偏移量（OFFSET 100000）带来的数据库性能坍塌 - 响应体结构尽量扁平，避免嵌套过深（如
{data: {list: [...], total: 123}}），bootstrap-table的responseHandler需显式解包 - 首次加载建议限制在 20–50 条，避免首屏白屏时间过长；后续每次追加控制在 30–100 条之间，太多易卡顿，太少请求太频
最常被忽略的一点：滚动加载失败时，前端必须保留已加载数据并显示重试按钮，而不是清空整个列表——bootstrap-table 默认不处理错误状态，得自己在 ajaxOptions.error 里补逻辑。
