真正可恢复的备份方式是JSON+原始图哈希校验，即用结构化JSON记录热区数据并绑定原始图SHA-256哈希值，包含基准尺寸、shape、数值型coords数组、href、alt及人工label，确保坐标可溯源、可验证、可协作。

不能只靠 HTML 源码备份 coords 数据——它既没结构、也没元信息，一改就丢，且无法还原设计意图。

为什么直接存 HTML 的 area 标签不是真备份

HTML 中的 coords 是纯字符串，比如 "120,85,240,160"，它不包含： - 这个区域对应哪个业务模块（如“华东销售入口”） - 坐标是基于哪张原始图（naturalWidth=1200？还是 @2x 版？） - 画的是矩形还是多边形（shape 属性可能被删或覆盖） - 是否已适配过缩放逻辑（JS 动态重算前的原始值？还是当前显示值？） 一旦团队协作、图片替换、或重构页面，仅靠 DOM 里的 area，你根本分不清哪组坐标该用、哪组已废弃。

真正可恢复的备份方式：JSON + 原始图哈希校验

把热区数据抽成结构化 JSON，并绑定到原始图文件本身： - 用 img.naturalWidth 和 img.naturalHeight 记录基准尺寸 - 每个 area 提取为对象，含 shape、coords（数组，非字符串）、href、alt、label（人工备注） - 对原始 PNG/JPG 文件计算 SHA-256，存在 JSON 的 sourceHash 字段里

{
  "sourceHash": "a1b2c3d4...",
  "baseSize": { "width": 1200, "height": 800 },
  "areas": [
    {
      "id": "shanghai",
      "shape": "poly",
      "coords": [60,40,120,30,110,90,60,80],
      "href": "/regions/shanghai",
      "alt": "点击进入上海地区详情",
      "label": "华东总部热区"
    }
  ]
}

这样下次换图时，只要哈希不匹配，就知道坐标需重新量取；团队交接时，也能一眼看出每个 coords 数组对应哪块业务。

Wechat Article Html

将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。

下载

别跳过的三个落地细节

实际操作中容易漏掉这些关键点： - coords 数组必须用 Number 类型存，别留字符串（避免后续 JS 计算时隐式转换出错） - 多边形顶点顺序要统一（推荐顺时针），否则某些 SVG 导出工具会渲染反色或镂空 - 备份 JSON 文件名建议带原始图名和日期，例如 map-cn-20261020.json，而不是 hotspots.json——后者在项目有多个地图时立刻混乱

真正麻烦的从来不是“怎么存”，而是“怎么确认这组坐标还有效”。哈希校验+结构化字段，才是让下次修改不从零开始的底线。