fix: paginate operational list pages

docs/first-version-development-requirements.md

@@ -1800,3 +1800,12 @@
 - 查看签名明细时使用“通道行 × 运营商列”矩阵，每个有数据的单元格展示提交次数、成功率、平均到达时间及提交失败数量；所选日期无真实提交显示`—`，不据此推断通道不支持该运营商。
 - 平均到达时间只统计成功送达的提交尝试，从该通道提交受理时间开始，到该通道成功回执完成为止；长短信以全部成功分片完成时间为准。
 - 签名列表提供签名、企业或应用关键字查询和后端分页；查看详情不应依赖前端模拟数据或浏览器本地存储。
+# 列表查询性能与分页约束（2026-07-28）
+
+- 除通道组外，运营端和客户端业务列表必须使用真实后端、数据库分页；浏览器不得先拉取完整结果再切片分页。
+- 本轮覆盖短信记录、短信任务进度、报备任务、报备记录、企业应用、企业签名及引流、企业模板、短信通道、上行短信、充值记录，以及对应客户端页面。
+- 列表筛选条件必须传入后端并参与总数统计；分页响应统一包含 `items`、`total`、`page`、`pageSize`。页面翻页只读取目标页，筛选和重置回到第一页。
+- 短信记录列表只返回当前页面渲染及详情所需字段；CSV 导出使用独立后端导出接口，不通过浏览器当前页或全量列表拼接。
+- 企业应用和签名等下拉框使用轻量选项接口，不得为了选择器加载连接、资料、报备任务等完整关联对象。
+- 分页排序字段应有数据库索引；Nginx 对 JSON、JavaScript、CSS、CSV、文本和 SVG 响应启用 gzip，降低传输与解析等待。
+- 通道组本轮按用户明确要求排除，保留现状，后续如数据规模扩大再单独改造。

docs/system-functional-test-cases.md

@@ -3987,3 +3987,25 @@ npm run verify:phase8
 | TC-ANALYTICS-SIGNATURE-011 | 点击“查看明细” | 打开右侧详情抽屉，展示运营商概览及通道×运营商矩阵；Esc、关闭按钮和遮罩均可关闭 |
 | TC-ANALYTICS-SIGNATURE-012 | 所选日期没有已登记签名发送 | 返回真实空状态，不显示演示或历史日期数据 |
 | TC-ANALYTICS-SIGNATURE-013 | 同一运营商的一条业务短信首通道失败后切换通道并最终送达 | 运营商概览计1条业务短信、最终成功率为100%；通道矩阵仍分别记录两次真实提交 |
+# 列表后端分页与响应性能测试（2026-07-28）
+
+## TC-LIST-PERF-001 短信记录真实后端分页
+
+1. 进入运营端短信记录，选择日期并查询。
+2. 验证请求携带 `page/pageSize`，响应为 `items/total/page/pageSize`，`items` 不超过页容量。
+3. 翻到下一页，验证数据库返回目标页且页面未在浏览器缓存全量记录。
+4. 验证关联提交、回执、下游投递仅属于当前页短信；CSV 下载调用独立导出接口。
+
+## TC-LIST-PERF-002 其他运营端列表分页
+
+逐页验证短信任务、报备任务、报备记录、企业应用、企业签名、企业模板、短信通道、上行短信和充值记录。筛选在后端生效，总数与条件一致，翻页只请求当前页；通道组不在本轮范围。
+
+## TC-LIST-PERF-003 客户端列表分页
+
+逐页验证短信明细、批量任务、应用、签名与引流、模板、上行短信和充值记录。验证租户边界不变、筛选回到第一页、选项接口仅返回下拉必需字段。
+
+## TC-LIST-PERF-004 数据库索引与压缩
+
+1. 应用分页索引 migration。
+2. 对短信、任务、报备、应用、签名、模板、通道、上行和充值分页 SQL 执行计划进行检查。
+3. 携带 `Accept-Encoding: gzip` 请求大于 1KB 的 JSON，验证响应 `Content-Encoding: gzip`。

docs/testing-progress.md

@@ -2671,3 +2671,10 @@ git diff --check
 - `.deployed-commit=95c052e9ea987f58c34002543331c2b75f36c642`；API、Gateway、Nginx、PostgreSQL、MinIO和Redis均active，`12026/17890/8090/3000/6379/5432/9000`均监听，API/Gateway health与Redis PONG通过。`gateway.submit.commands`消费者1、`pending=0`、`lag=0`，12个通道TPS配置键存在，发布后API/Gateway error级journal为0。
 - 公网首页、运营端、客户端和API health均HTTP 200，公网CMPP 17890 TCP可连接。4条active供应商通道中3条为`connected 1/1`；“会员营销-富泷”为`failed 0/1`，数据库记录`authentication / connect response status: auth failed`并保留系统自动重连，未修改账号、密码或启停状态。120秒内活跃下游客户连接为0。
 - 部署源码和前端产物均包含`.ui-query-actions`、两个报备筛选布局类及“条业务短信”新口径文案。应用内浏览器仍因无已登录运营会话停留在图形验证码登录页，未绕过验证码或虚报登录后视觉验收；本次未发送、重投或补发真实短信。
+# 2026-07-28 全业务列表后端分页与短信记录性能修复（发布前）
+
+- 预生产短信记录页面卡顿根因已定位：页面一次读取443条短信及其760条提交、1492条回执和435条下游投递，JSON约4.47MB，再在浏览器切出25条；数据库基础查询不足1ms，主要耗时来自不必要的关联装载、序列化、网络传输和前端解析。
+- 除用户明确排除的“通道组”外，显式浏览器切片分页已全部移除。运营端短信记录、短信任务、报备任务/记录、企业应用/签名/模板、短信通道、上行短信和充值记录，以及客户端短信明细、批量任务、应用、签名/引流、模板、上行短信和充值记录，均改为真实PostgreSQL分页与后端筛选。
+- 短信记录列表改为当前页最小字段与当前页关联数据，新增独立后端CSV导出；企业应用、签名下拉改用轻量选项接口。新增分页排序索引migration `20260728223000_optimize_list_pagination`，部署脚本为JSON及静态文本资源启用gzip并在重启前执行`nginx -t`。
+- Prisma format、validate、generate通过；Node.js v24.14.0下前端与API TypeScript检查通过。API全量26 suites / 367 tests全部通过，新增短信记录数据库分页页码、容量、总数及目标页关联约束；Jest仅保留既有`--forceExit`异步句柄提示。后续构建、Gateway、安全门禁、提交、推送及预生产部署结果在本节继续补记。
+- 既有`api/tsconfig.build.tsbuildinfo`、`tsconfig.tsbuildinfo`、`outputs/`和空文件`=`继续视为构建/临时产物，不纳入提交。