Material主题滚动卡顿本质是CSS渲染策略冲突，因其将.table_container的overflow-x设为hidden且未加white-space:nowrap，导致浏览器强制渲染整张宽表，尤其在移动端WebView中硬件加速弱而掉帧。

Material 主题的滚动卡顿本质是 CSS 渲染策略冲突

不是主题“慢”，而是它把 .table_container 的 overflow-x 设为 hidden，同时没加 white-space: nowrap，导致浏览器强行渲染整张宽表——尤其在移动端，ios safari 和部分安卓 webview 对 overflow: scroll 的硬件加速支持弱，一滚动就掉帧。

Material 主题下必须覆盖的三处 CSS 规则

直接编辑 phpmyadmin/css/material.css（或你当前启用的主题 CSS），在 @media (max-width: 768px) 块内追加：

• .table_container 加 overflow-x: auto + white-space: nowrap：让横向滚动可触发，且字段名不换行截断
• .table_container table 加 display: block：脱离表格默认渲染流，避免宽度撑破容器
• th, td 加 min-width: 120px（可按需调小）：防止小屏下单格被压缩到文字重叠或图标错位

改完仍卡？优先排查缓存与 JS 干扰

常见失效原因不是 CSS 写错，而是没生效：

page-agent 浏览器控制（CDP）

使用 page-agent CLI（CDP）控制浏览器；CLI只能通过 GitHub Release 的 .tgz 安装，npm 官方包暂未发布。

下载

• 浏览器缓存了旧 CSS：清空缓存，或在 URL 后加 &v=2 强制刷新（确保 v 值与 config 中 $cfg['VersionCheck'] 不冲突）
• Nginx/CDN 缓存了 CSS：临时关掉 expires 指令，或用 curl -I 看响应头里的 Cache-Control
• Material 主题自带 JS 动态重写了 table 样式：临时切换回 pmahomme 主题测试，确认是否 JS 干扰

真大数据量时，Material 主题的 CSS 优化只是止痛剂

超过 50 列 × 1000 行，光靠 CSS 滚动只是“看起来能动”。真正瓶颈在首次渲染宽度计算和滚动时重绘范围——这两步 Material 主题没做任何特殊处理，反而因额外动画层加重压力。此时必须配合后端动作：

• SQL 查询里用 LIMIT 分页查，别点“浏览全部”
• 导出用 CSV 而非网页表格，避免前端渲染整表
• 用 DevTools 的 Rendering 面板勾选 “Paint flashing”，看滚动时哪些区域在疯狂重绘——那才是该动手的地方

Material 主题的滚动卡顿问题，核心不在“主题本身多漂亮”，而在它默认放弃了对宽表滚动的底层控制权；修复的关键不是换主题，而是用最小侵入方式夺回渲染主导权。