撤销和重做功能的最佳实践包括：1. 明确操作粒度，避免过频记录；2. 使用blur或防抖的input事件触发状态保存；3. 维护撤销/重做栈，及时清空重做栈；4. 设置历史记录上限，防止内存溢出；5. 提供按钮状态反馈，提升可感知性。
表单中的历史记录和撤销/重做功能，本质上是通过记录表单状态的变化或用户操作序列来实现的。我们可以将每次重要的表单修改保存下来，形成一个可追溯的时间线，然后通过“前进”和“后退”指针来回切换这些历史状态，从而实现撤销和重做的效果。这听起来有点像时间旅行，但其实就是数据管理的小把戏。
解决方案
实现表单的历史记录和撤销重做，我个人觉得最直观也最常用的方法是基于“状态快照”的模式。
想象一下，你有一个表单，里面填了各种数据。每当你完成一个重要操作，比如修改了一个输入框的值，或者勾选了一个复选框，我们就把当前整个表单的数据“拍个照”，保存下来。
具体来说，你需要维护两个核心的东西：一个“撤销栈”（undo stack）和一个“重做栈”（redo stack）。
初始状态入栈： 当表单加载完成时，或者说用户开始编辑之前，把表单的初始数据作为第一个状态，推入“撤销栈”。这很重要，这是你的起点。
-
捕捉变化并保存： 这是核心。你需要在表单的各个输入控件上监听变化事件，比如
input
事件（实时性强，但可能过于频繁）、change
事件（失去焦点或选择改变时触发）或者blur
事件（失去焦点）。我通常会选择blur
事件，或者对input
事件进行防抖（debounce）处理，避免每次按键都生成一个历史记录，那样历史记录会非常庞大且无用。 当检测到一次“有意义”的改变时，获取当前表单的完整数据（或只获取改变的部分，这取决于你的设计复杂度和性能需求，但对于普通表单，完整数据快照更简单粗暴有效），然后：- 将当前表单数据推入“撤销栈”。
- 清空“重做栈”！ 这一点至关重要。一旦用户在某个历史点上做了新的修改，那么所有“未来”的重做历史就都失效了。比如你撤销了两次，然后又改了点东西，那之前被撤销掉的那些“前进”操作就没意义了。
-
执行撤销（Undo）：
- 首先，检查“撤销栈”是否至少有两个元素（因为栈顶是当前状态，我们想回到上一个状态）。如果只有一个，说明已经是初始状态了，没得撤了。
- 将当前表单数据（也就是撤销栈的栈顶元素）推入“重做栈”。
- 从“撤销栈”中弹出栈顶元素。
- 将新的栈顶元素（也就是上一个历史状态）重新渲染到表单上。
-
执行重做（Redo）：
- 检查“重做栈”是否为空。如果为空，说明没有可以重做的操作了。
- 将当前表单数据（也就是撤销栈的栈顶元素）推入“撤销栈”。
- 从“重做栈”中弹出栈顶元素。
- 将弹出的元素（也就是下一个历史状态）重新渲染到表单上。
-
一些细节考虑：
- 历史记录上限： 栈可能会无限增长，占用内存。可以设置一个最大历史记录数，当栈的长度超过这个限制时，移除最底部的旧记录。
- 复杂数据结构： 如果表单数据很复杂，比如嵌套对象或数组，确保你的“快照”是深拷贝，避免引用问题。
- 性能： 如果表单非常大，每次都保存完整快照可能会有性能开销。这时可以考虑“增量保存”，只记录改变的部分和改变的方式（类似命令模式），但实现会复杂很多。对于大部分表单，完整快照是可行的。
- 用户体验： 最好能给用户一个直观的反馈，比如撤销/重做按钮的禁用状态。
如何选择合适的时机来保存表单历史状态？
选择合适的时机来保存表单历史状态，这其实是个权衡问题，关乎用户体验和系统性能。我个人在实际项目中摸索过几种方案，每种都有它的脾气。
最粗暴的方式是监听每个输入框的
input事件。好处是实时性极强，你每输入一个字符，它都能被记录下来。但问题也显而易见：历史记录会爆炸式增长，几秒钟就能生成几十条记录，这不仅占用大量内存，也让“撤销”变得非常琐碎，用户可能只想撤销“填完一个字段”这样的操作，而不是“输入了一个字母”。这种方式通常不太推荐，除非你的应用场景就是需要这种粒度极细的实时记录，比如一个富文本编辑器在输入时的临时快照。
更常见且我更倾向的做法是监听
blur事件，也就是输入框失去焦点的时候。当用户完成一个字段的输入并切换到下一个字段时，才保存当前表单的状态。这样做的优点是：
- 粒度适中： 通常一个字段的填写可以算作一个完整的操作单元。
- 减少噪音： 避免了中间输入过程的无意义记录。
- 性能友好： 触发频率大大降低。
但
blur事件也有它的局限性，比如用户可能在一个字段里停留很久，或者不切换焦点就直接点击了提交按钮，那这个字段的修改可能就不会被记录。
为了兼顾实时性和效率，一个更优雅的方案是结合防抖（Debounce）。你可以监听
input事件，但不是立即保存，而是设置一个定时器。如果在一定时间内（比如300ms到500ms）没有新的
input事件发生，才执行保存操作。这样，用户快速输入时，只会保存输入停止后的最终状态；而如果输入缓慢，也能保证及时记录。这对于那些需要实时反馈但又不想历史记录过于臃肿的场景非常适用。
还有一种情况，是用户执行了某个“大”操作，比如在一个动态添加行的表单中，用户点击了“添加一行”按钮。这种操作本身就应该被视为一个独立的、需要被撤销的历史点。这时，你可以在这个按钮的点击事件中手动触发一次状态保存。
总的来说，没有一劳永逸的最佳时机，你需要根据表单的复杂程度、用户操作习惯以及对撤销/重做粒度的要求来灵活选择。对我来说，
blur事件配合关键操作的手动触发，再辅以必要时的防抖处理，通常能满足绝大部分需求。
