Fabric.js 画布状态保存与恢复：JSON 序列化最佳实践

在基于 Fabric.js 开发的图文编辑器、海报设计器以及低代码看板中，画布状态的持久化与恢复依赖于以 JSON 为媒介的序列化（canvas.toJSON() / toObject()）和反序列化（canvas.loadFromJSON()）机制。实现这一闭环的关键不仅在于调用 API，更在于解决三大工程挑战：非标自定义属性在序列化过程中的丢失、远程图片与 Web 字体在反序列化阶段的异步时序脱节，以及多层撤销/重做（Undo/Redo）状态栈中的内存泄露与死循环事件触发。本文将针对这些核心痛点，提供规范的实现流程、边界防御方案以及生产级封装示例。

一、序列化与反序列化的核心运行机制

Fabric.js 的状态管理采用声明式的 JSON 契约。调用 canvas.toJSON() 时，Fabric.js 会自顶向下遍历画布内部的 _objects 数组，提取每个图形实例的几何坐标（left、top、width、height、scaleX、scaleY、angle）、层级样式（fill、stroke、opacity）以及全局属性（backgroundColor、clipPath 等），最终拼装为一个标准的纯文本 JSON 树。

与之相对，canvas.loadFromJSON(json, callback, reviver) 则是一个高度依赖异步工厂的反向解析过程。它逐个解析 JSON 中的对象声明，根据 type 字段（例如 rect、image、i-text）查找对应的 Fabric 构造器进行实例化。在这个过程中，普通矢量对象是同步生成的，而包含远程链接的 fabric.Image 则必须拉取网络资源，这正是反序列化必须依赖回调机制的根源所在。

二、保留业务自定义属性的 3 种标准解法

初学者最常遇到的问题是：在图形对象上扩展了业务字段（如 obj.id = 'node-101' 或 obj.locked = true），但在执行 canvas.toJSON() 后，导出的 JSON 中这些字段全部不翼而飞。这是由于 Fabric.js 的内部保护机制只会导出官方白名单内的渲染属性，任何附加属性默认都会被忽略。

方案 1：调用时显式传入白名单数组（局部生效）

如果仅在特定导出节点需要保留特定属性，可以在调用 toJSON() 或 toObject() 时将自定义字段名称以数组形式作为参数传入。

// 显式指定要附加导出的字段名
const customProperties = ['id', 'name', 'locked', 'customType', 'bindData'];

// 导出包含自定义属性的 JSON
const jsonOutput = canvas.toJSON(customProperties);
console.log(jsonOutput);

方案 2：全局覆写 fabric.Object 原型方法（推荐工程使用）

在大型前端项目中，每个模块都手动传递白名单数组不仅容易遗漏，而且不利于统一维护。更优雅的工程方案是在项目初始化时，全局拓展 fabric.Object.prototype.toObject。这样无论是矩形、路径、文字还是嵌套分组，都会自动携带自定义属性：

// 保存 Fabric 原始的 toObject 逻辑
const originalToObject = fabric.Object.prototype.toObject;

// 统一扩展业务需要的核心字段列表
const GLOBAL_CUSTOM_PROPS = ['id', 'name', 'customType', 'locked', 'zIndex'];

fabric.Object.prototype.toObject = function(additionalProperties = []) {
  return originalToObject.call(this, [
    ...GLOBAL_CUSTOM_PROPS,
    ...additionalProperties
  ]);
};