表单填到第三屏才想起保存还在最底下，用户来回滚，这颗按钮是不是该一直贴在屏幕上？

长表单的保存入口，先量字段规模和分段方式，再谈按钮摆在哪。按 2026 年后台交付的常见口径：字段 10 项上下、一屏能看完的，页尾一颗保存就够；字段到 15 项以上、需要滚两屏的，优先考虑吸底操作条或分段保存。只在页尾放一颗，常出现「填完了不知道往哪点」。吸底条也不是默认答案，最后一项被遮挡、移动端键盘弹起时按钮跟着上浮，这两件事不提前处理，反而更容易误点。

保存按钮的位置，实质是填完之后那一步好不好找

用户在长表单里的注意力跟着输入框走，视线停在最后填的那一格。提交入口在屏幕外，他要么继续往下滚、要么以为还没填完，要么按返回去看别的。交付里较常见的抱怨不是按钮不好看，而是「填了半天没找到提交」，这通常说明入口的可达性没算进设计范围。

位置问题还会放大成数据问题：用户以为没提交成功，重填一遍，同一张单据出现两条；或在返回时被离开确认拦住，已填内容丢失。判断标准很直接——不管滚到表单哪个位置，提交入口能不能在一屏之内被看到或被想到，做不到就说明入口没排好。

• 可见不等于可达：吸底条被键盘顶走、被底部安全区压住，都算看不见。
• 可达还要可辨：吸底条里同时塞保存、保存并新建、重置，主次不分等于没有主按钮。
• 出现时机也要看：字段少而分散时，分段保存更贴近填写节奏。

先量字段再看分段，三步定吸底还是页尾

不少项目一上来就问吸底好看还是页尾好看，这属于跳过判断直接挑形式。交付里较稳的顺序是先量字段、再看分段、最后看提交代价，三步过一遍，位置的答案往往自己就出来了。

1. 数字段和滚动屏数：字段 8-12 项、PC 一屏装得下的，页尾单按钮即可；到 15 项以上、需要滚动两屏左右，再考虑吸底或分段。
2. 看能不能按主题分段：基础信息、联系信息、结算信息这种天然分组，分段保存比吸底更稳；字段之间强依赖、要一次填完的，才轮到吸底。
3. 看提交代价：提交后能改、能撤回的，吸底条可以放宽；提交换来的是审批流、外发通知、扣减库存这类不可逆动作，吸底条旁边要留明确的确认线索，按钮别长得像「下一步」。

这三步的用意是把按钮位置还原成填写节奏。字段少而提交重，问题在确认；字段多而提交轻，问题在可达。两种问题不是同一个解法。

四种做法摆一起比，差别在改稿轮次和联调量

同一个问题往往有四条路，差别不在视觉，而在字段规模、改稿轮次和开发工作量。下面这组按经验区间给出，具体项目还要按实际字段和依赖关系调整。

• 页尾单按钮：适合 10 项以内的表单；开发和改动量低，改稿常见区间是 0-1 轮；字段一多就暴露可达性问题。
• 吸底操作条：适合 15 项以上、字段强依赖、要一次提交的表单；遮挡、键盘、层级三处要额外处理，联调工作量比页尾方案高一档，常见多出 0.5-1 人日。
• 分段保存：适合能按主题自然分组的表单；用户中断代价低，但要额外定义部分保存算不算有效数据，前后端各要一轮对齐。
• 自动草稿加明确提交：适合填写耗时长、中途容易被打断的场景；草稿要能说清「已暂存、尚未提交」，否则用户会以为已经交上去了。

常见误区是把四种叠着上：既吸底、又分段、又自动草稿，一屏里出现两个类似主按钮的动作，用户反而不知道点哪个。方案可以组合，但主提交入口在整条流程里应当只有一个，其余动作降到次级样式或收进菜单。

吸底条容易出问题的地方

吸底条在 2026 年的后台交付里已经比较常见，但它不是加一条 fixed 就完事。问题主要集中在遮挡和层级两处：容器没留出底部内边距，最后一行输入框被压在条下面；移动端键盘弹起时吸底条跟着上浮，正好盖住正在填的那一格；页面本身已有分页条或批量操作条时，两条叠在一起互相打架。

交付现场较常见的一种情况是：预算和周期都压得紧，只出一套 PC 稿就直接适配移动端，吸底条的内边距和键盘处理没写进标注，前端按固定高度实现。验收时甲方拿手机填一遍，发现最后两项看不到也点不到，回来返工。按经验区间，这一轮返工通常要补 1-2 天改稿加一次回归测试，比一开始就把标注写清贵不少。所以交付前先核对三件事：底部内边距是否按吸底条高度留足、键盘弹起时条是隐藏还是让位、条内按钮是否只有一个主操作。

• 没留底部内边距：最后一项与吸底条重叠，属于较常见也较好修的一类。
• 键盘弹起不处理：移动端填到最后几项时，条和键盘抢位置，用户看不到自己输入的内容。
• 条内按钮过多：保存、重置、取消并列，误触率上升，重置与保存相邻时更明显。
• 与页面原有底部元素叠加：列表页、详情页各自有底栏时，要先确认谁让位。

做到什么程度算合格

验收时不必争论风格，用几条可核对的口径过一遍就够，这些可以直接写进交付验收清单，和前端一起对。

• 滚到表单任意位置，主提交入口在一屏内可见，且不被浮层或键盘遮挡。
• 吸底条只保留一个主操作，重置、取消在视觉权重上明显低于主操作。
• 必填校验结果能定位到具体字段，并自动滚到出错位置，不需要用户自己找。
• 提交后成功与失败两种状态的文案能区分，不共用一句「操作完成」。
• 移动端在键盘弹起、收起两种状态下各实测一遍，确认最后一项和提交入口都够得着。

适用场景与边界

适合上吸底或分段的情况：后台录入类长表单、要连续填十几项以上、用户中途可能被打断、提交动作偏重。这类表单里入口可达性直接影响完成率，投入处理遮挡和键盘是值得的。

不必上的情况：字段只有五六项、一屏内能全部看完的表单，页尾一颗按钮就够，硬加吸底条多出一层视觉噪音；以浏览和确认为主的详情页，也不该为了统一套上吸底操作条。边界可以这么记：要滚动才能看到全部字段，才讨论吸底；一屏装得下，就别加。

另外，涉及审批、扣减、外发通知这类不可逆提交时，吸底条只能解决找得到，解决不了点错了。这类场景要在提交前补一次确认，或把提交结果做成可回溯的记录，不能只靠按钮位置兜底。

常见问题

表单只有五六项字段，也要做吸底保存吗？

不必。字段少、一屏能看完时页尾一颗按钮更清爽，硬加吸底条会多占一条视觉带，也可能和页面原有底栏冲突。

吸底条会不会把最后一项挡住？

会，这是较常出现的问题。容器底部要按吸底条高度留足内边距，交付前滚到底部实测一次，确认最后一行输入框完整露出。

分段保存是不是等于把长表单拆成好几页？

不等同。分段可以同页分块，也可以分步，关键差别在于每段保存后系统里算不算有效数据，这一点要先和业务方对齐再动手。

自动草稿能替代保存按钮吗？

不能。草稿只解决不丢，解决不了已提交。界面上要把暂存和提交两种状态写清楚，否则用户会以为已经交上去了。

如果你正在做一版字段偏多的后台表单，可以先把字段数、滚动屏数和提交代价三项列出来，再决定页尾、吸底还是分段，比直接改稿省事。需要提醒的是，本文口径针对录入型表单；以浏览、审批、对账为主的后台页面，入口设计要另算。