phpMyAdmin Operations 标签页不支持分栏或卡片化，因其服务端生成固定表格结构、无现代前端框架、DOM强依赖且官方不鼓励UI定制；替代方案是使用SQL书签执行高频操作。
phpMyAdmin 的 Operations 标签页不支持分栏或卡片化
phpmyadmin 本身没有提供对 operations 标签页的 ui 布局定制能力，包括分栏、卡片、折叠、拖拽等。它的 html 结构是服务端生成的固定表格，前端无 vue/react 等框架支撑，css 类名也未暴露为可安全覆盖的接口。
常见错误现象：在自定义 CSS 中强行用 display: grid 或 float 改 #operations_table，结果表单控件错位、AJAX 提交失效、部分按钮点击无响应——因为 JS 逻辑强依赖原始 DOM 顺序和 class 层级。
- 所有操作项（如“更改表名”“添加字段”“复制表”）都包裹在同一个
<table>内，无法按功能分组隔离 - PHP 后端模板（
tbl_operations.tpl.php）硬编码了结构，升级后自定义会被覆盖 - 官方明确不鼓励修改界面布局，issue tracker 中多次关闭类似需求
替代方案：用 SQL 页面 + 自定义书签快速执行高频操作
与其折腾 Operations 页面，不如绕过它——把常用操作固化为可一键执行的 SQL 语句，存在浏览器书签或 phpMyAdmin 的 SQL 标签页中。
使用场景：批量重命名字段、添加索引、切换存储引擎、清空并重置自增 ID。这些操作比点选表单更可控，也更容易复用。
- 例如重命名字段：
ALTER TABLE `users` CHANGE `user_name` `username` VARCHAR(255) NOT NULL; - 加索引：
CREATE INDEX idx_status_created ON `orders` (`status`, `created_at`); - 清空并重置：
TRUNCATE TABLE `logs`;（注意不是DELETE，否则自增不归零） - 书签 URL 示例（含自动填充 SQL）：
https://your-pma.example.com/sql.php?sql_query=TRUNCATE+TABLE+%60logs%60%3B&server=1&db=test&table=logs
真要改界面？只能动 PHP 模板 + 手动维护升级补丁
如果你有运维权限且愿意承担后续升级成本，可以局部修改 tbl_operations.tpl.php，但必须清楚代价。
参数差异：新版 phpMyAdmin（5.2+）已将部分操作移入 AJAX 加载的 div#operations_ajax，静态模板只控制头部和基础表单，JS 动态注入的内容无法通过改 tpl 覆盖。
- 路径示例：
/usr/share/phpmyadmin/templates/table/tbl_operations.tpl.php（Debian 系） - 不要直接改
<tr><td>行内结构，优先用<div class="card">包裹整块逻辑区（如“复制表”区域），再配轻量 CSS - 每次升级 phpMyAdmin 后，必须手动比对 diff 并重新打补丁，
dpkg --force-confold会丢掉你的修改 - 禁用 CSP 或调整
$cfg['CSPAllow']，否则内联样式或脚本可能被浏览器拦截
为什么官方不做卡片化？性能与兼容性现实
phpMyAdmin 运行在低配 VPS、老旧嵌入式设备甚至本地 XAMPP 上。Operations 页面需兼容 IE11（直到 5.1.x）、PHP 7.2+、MySQL 5.5+，而卡片化涉及 flex/grid 布局、JS 交互状态管理、异步加载分组数据——这会显著增加首屏 JS 体积和渲染延迟。
真实影响：在 1GB 内存的树莓派上打开带 30+ 字段的表的 Operations 页，DOM 节点数超 2000，若再加卡片折叠动画，滚动卡顿明显，表单提交前校验可能超时失败。
- 移动端适配靠的是 viewport 缩放，不是响应式栅格，卡片在小屏上反而更难定位目标按钮
- 无障碍访问（WCAG）要求所有操作项保持线性阅读顺序，卡片打乱 DOM 顺序会破坏屏幕阅读器流
- 插件生态（如 Designer、PDF Export）均假设
#operations_table是标准 table 结构，改了就可能崩
复杂点不在“能不能做”，而在“改完之后谁来验证 MySQL 8.4 的新字段类型、MariaDB 11 的 JSON 函数、以及未来 WebAssembly 加速的查询面板是否还兼容这个改动”。没人负责这事。
