手机上看后台表格，用户总漏看右边那几列，是该加提示还是干脆改成卡片？

手机端后台表格不该直接把桌面端宽表横着滑过去。判断依据不是屏幕小，而是这一屏用户到底在干什么：如果是逐行比对同一批字段，横滑加冻结首列还能用；如果是处理某一条记录，把每行拆成卡片更稳。按 2026 年常见的移动端后台交付经验，字段超过 5-6 列、首屏只能露出一小半时，横滑的查找效率会明显掉下来。

一、手机端表格不是缩小版的桌面表格

表格在桌面端承担的是同屏比对：一屏十几行、八到十个字段都能看全，用户扫一眼就能定位异常。手机竖屏的有效宽度常见在 360-430px 之间，扣掉页面内边距后真正能放内容的宽度更少，同样列数会被压成每条只有几十像素的窄条，中文两个字就可能换行。

• 横向滚动是隐藏行为：用户看不见右侧还有列，容易以为数据就这些，这在后台场景里是高频的误判来源。
• 触控目标不达标：移动端可点区域的经验区间常按 44-48px 核对，表格里的文字链、小图标按钮几乎都低于这条线。
• 拇指遮挡：横滑时右侧字段正好被手指压住，松开才看得见，核对数据的体验很差。

所以手机端要么减列，要么改行的呈现方式。只在外面套一个横向滚动条，本质是把问题藏起来，而不是解决。

二、先分清这一屏是比对，还是处理单条

这是决定横滑还是卡片的分水岭。同一张订单表，财务在核对金额是比对视角，客服在处理售后是单条视角，两者的更合适方案并不一样，很多返工就出在把两者当成了同一件事。

1. 比对视角：用户需要在同一字段的不同行之间横向比较，例如按金额排序、按状态筛选。字段数不宜超过 5-6 个，保留横滑并冻结首列。
2. 单条视角：用户点进去只处理一件事，字段可以多，但一次只关心一行，卡片式明显更合适。
3. 混合场景：列表用卡片露出 3-4 个主字段，点开进详情页看完整字段，是 2026 年比较常见的折中做法。

需要提醒的是：一旦把比对需求做成了卡片，卡片里又没有可比对的列，用户只能一条条点进去看，反而把效率拖垮了。

三、三种常见做法怎么对比

横滑、卡片、折叠次要字段，这三种做法各有各的代价，选错往往不是因为难看，而是因为任务类型没对上。

• 横滑加冻结首列：适合字段少、要横向比对的场景。交付经验区间是字段 3-6 列，列宽合计控制在 600-900px 内。代价是用户容易漏看右侧列。
• 每行拆卡片：适合单条处理、字段多但每次只看一行。单张卡片常见 4-7 个字段加 1 个主操作。代价是长列表滚动距离变长，一屏可能只看 2-3 条。
• 折叠次要字段：列表只露主字段，次要字段用展开或进详情页。适合字段结构稳定、有明确主键的表。代价是要额外设计展开态和展开后的层级。

三种并不互斥。常见组合是列表用卡片露主字段、详情页完整展示、列表顶部保留筛选与排序入口。

• 字段数量：横滑适合 3-6 列；卡片适合每条 4-7 个字段。
• 一屏可见条数：横滑常见 6-10 条（行高约 48-64px）；卡片常见 2-4 条。
• 主要风险：横滑是漏看列；卡片是滚动疲劳、主键不突出。
• 实现成本：横滑要处理固定列与横竖滚动嵌套；卡片要重排结构、重新规划行高与操作区。

四、改成卡片时常踩的三个坑

在项目里常见的情况是：原型只给了横滑表格，开发按 1:1 实现，测试期才发现运营在手机上根本找不到金额那一列，只能回头重排卡片。按常见交付区间，这类返工通常落在 2-3 个工作日，还会挤掉后面的验收时间。按企业项目交付习惯，动手前会先核对字段优先级和主键，再决定呈现方式。

• 卡片里把全部字段平铺：信息密度反而不比横滑低，用户仍然要一行行读，卡片的意义就没了。
• 丢了主键标识：卡片顶部没有订单号、名称或编号，用户复制、截图、报错时无法指认是哪一条。
• 操作按钮全堆在右上角：三四个按钮挤在一起，触控热区互相重叠，误点概率明显上升。

合格线大致是：卡片顶部一个清晰主键，中间 3-5 个关键字段，底部或右上角保留 1 个主操作，其余操作收进更多菜单。

五、怎么判断改完是合格的

判断标准要能核对，不能停留在感觉上。以下几项可以在上线前逐条过一遍。

• 首屏不滑动、不点击就能看到主键与状态字段。
• 一屏至少完整展示 2 条卡片，或者 6 行以上表格数据。
• 横滑方案有滚动提示，例如边缘渐变，或让下一列露出 8-16px。
• 触控目标按 44-48px 的经验区间核对，密集列表也别低于 40px。
• 用真机核对，而不是只在设计稿缩放预览里看，字体、间距和固定定位的表现经常不一样。

六、适用场景与边界

把表格改成卡片，适合手机端高频使用的后台，例如订单、工单、审批、客户列表，用户需要逐条推进处理。反过来，如果手机端只是偶尔查一次数据，一周用不了几次，横滑加冻结首列就够用，不必为此重构整个列表。

• 适合改成卡片：字段多、每条要独立处理、需要点进详情页继续操作。
• 适合保留横滑：字段少且必须横向比对，使用者是熟练的运营或财务角色。
• 不必大动：手机端仅作低频查看，改造收益低于改稿与联调成本。
• 不适合硬拆卡片：字段之间有强关联、必须同屏对照看的情况，拆开只会让用户来回点。

常见问题

手机上的表格一定要改成卡片吗？

不一定。字段在 5 列以内、用户要横向比对时，横滑加冻结首列更省事；字段多、每条独立处理时，才优先考虑卡片。

横滑表格用户总说找不到右边的列，怎么处理？

在表格右边缘做渐变提示，或让下一列露出 8-16px，同时把横向滚动条固定在表头下方，减少以为没有更多列的误解。

卡片里字段太多怎么办？

卡片只保留主键、状态和 3-5 个关键字段，其余收进详情页或展开区，判断标准是一屏能完整看到 2 条以上卡片。

卡片列表一屏只看得到两条，是不是太少？

要看信息密度。条目内容多时一屏 2-4 条属常见区间，可以用更紧凑的排版压到 3-4 条，但别把触控区域压到不足 44px。

移动端列表需要做排序和筛选吗？

要，但优先做筛选。字段多时排序入口容易被误触，常见做法是筛选放在列表顶部，排序收进筛选面板内。

动手前先问一句：这一屏用户是在比对字段，还是在处理单条记录，再按字段数量决定横滑或卡片。上线前用真机核对首屏是否露出主键、触控热区是否达标、横滑是否有提示。手机端只做低频查询的后台，不必强行重构成卡片，按 2026 年常见交付习惯，横滑加冻结首列已经够用。