Webflow/Framer 网站转干净 HTML 静态化全流程指南

接“能不能直接把整站代码给我”这类需求，我几乎每个月都要处理一次。客户拿着 Webflow 或 Framer 做的官网，既不想继续订阅平台，又想把站点搬到自己的服务器上，于是认为只要得到一个 HTML 文件，事情就算完了。可真拿到代码时会发现，Webflow 的 Export 包里有大堆 w-container、w-col 这类框架 class，Framer 更是连“下载整站静态代码”的入口都没有。这篇内容我会把自己处理这类需求的全套流程写清楚：怎么理解平台的导出逻辑，怎么把 Webflow/Framer 网站整理成可以直接静态部署、干净可交付的 HTML 文件，以及过程中会遇到哪些坑和怎么避。

适合看这篇文章的人有两类。一类是接单做官网的独立开发者或设计工作室，客户交付需要源码；另一类是把 Webflow/Framer 原型交给前端开发组的技术同学，你需要拆清楚哪些代码能留、哪些代码不能留。默认你了解一点 HTML/CSS/JavaScript 基础，但不需要写过复杂脚本，我会尽量把每步的原因也讲明白。

1. 平台产物和可交付产物，差距往往比你想象的大

1.1 Webflow/Framer 的代码是“编辑器友好”，不是“HTML 友好”

Webflow 有官方 Export Code 功能，这点很多人知道。但真正用过后会有一种奇怪的感觉：导出的 HTML 打开后，视觉上还算还原，可代码本身就像“编辑器在浏览器里的投影”。页面上到处都是平台生成的 class，样式分散在多个 CSS 文件里，script 标签引用的路径既有本地文件也有平台 CDN。为什么会这样？因为 Webflow 的导出首先得保证“你再导回去还能继续编辑”，它要对编辑器负责，而不是对最终交付负责。class 多、命名长，是为了在编辑器 UI 里能精确命中画布上的某个元素；CSS 拆分，是为了让可视化面板能映射到具体样式属性。

Framer 的问题更直接。新版 Framer 建出来的站点，线上跑的是一个近乎 React 运行时，浏览器拿到的 HTML 更像一个“启动壳”，真正决定版面的是打包后的脚本和一大堆内联样式。Framer 没有提供 Webflow 那种“下载项目代码”的按钮，只有 Publish 到自有域名或 framer.app 子域名。哪怕你把线上页面从头到尾看一遍，再右键保存，得到的也只是某个页面在特定时刻的 DOM 快照，而不是一套能独立维护的干净源码。理解了这一点就能明白，想让 Framer 站点变成干净 HTML，前面必须先有一层“静态化”，不可能像解压缩一个 zip 那样一步到位。

提示：两个平台都在持续调整功能细节，Webflow 的导出目录结构可能有版本差异，Framer 也可能逐步开放更多静态资源能力。本文讲的是底层思路，拿到具体新版本时，不要死记路径，按思路顺一遍最稳。

1.2 干净 HTML 文件的标准是什么

我评判一份交付文件是不是“干净 HTML 文件”，不看 HTML 里有没有平台前缀 class，而是看三点：能否脱离原平台运行，能否在任意静态服务器上部署，以及是否只保留真正会被页面用到的资源。

具体拆开就是：解压文件夹后，能找到一个 index.html，配套的 css/、js/、images/ 都在本地，页面字体和图标不依赖外部 Google Fonts 或平台 CDN；双击本地文件，或者丢到 Nginx 目录里，页面结构、导航点击、锚点跳转、图片加载都不出问题；浏览器开发者工具 Network 面板里，除第三方统计、地图这类有意保留的 iframe 请求外，没有偷偷去请求 Webflow、Framer 域名的资源。

另一种“干净”是代码阅读体验上的：HTML 里不要有大段无用注释，CSS 不要掺着编辑器自定义属性，JavaScript 如果一段代码只为了控制菜单开合，就没必要把整个交互框架打包进来。能做到这些，这份 HTML 才算到了能交给客户手里的程度，而不是“半成品”。注意，这不代表像素级一模一样，静态化过程中动效和交互可能被简化，我会在后文专门讲怎么取舍。

1.3 交付场景决定你要整理到什么程度

同一个网站，放在三种场景里，清理标准完全不同。

如果客户只是想把页面存档，以后打开做展示，那只要保证本地打开没问题，外部资源断网不可用也勉强能接受。如果客户要自建服务器正式上线，那字体必须本地化，外部 CDN 请求必须清理，图片必须下载到同目录，表单动作要换掉平台地址。如果客户后续要交给外包开发团队二次开发，那除了能跑，还要考虑代码可读性，HTML 结构要尽量语义化，CSS 最好按区块注释清楚。

我见过不少例子，交付人一句话没说就把一坨 Export zip 丢给客户，客户打开发现样式全乱，最后反过来说是网站没做好。所以不要想“反正文件能打开就行”，接到这种需求第一件事，先问清楚这份代码后续给谁用、放哪里跑，再决定动手深度。这个前置沟通能省掉后面一堆因为场景不清导致的返工。

2. 先选路线：两个平台的导出思路完全不同

2.1 Webflow：官方 Export 是起点，不是终点

Webflow 后台导出通常在项目设置的 Export Code 入口，点完会生成一个 zip。下载后解压，你会看到 index.html、css、js、images 等基础结构。这一步能拿到的是一份有本地化希望的原始工程，但它仍然带着 Webflow 运行时的味道。

部分 Webflow 站点，尤其用到了 CMS 集合、动态列表、会员制内容的，导出包里这些动态区块是空的，或者只留下给 Webflow 后台渲染数据的模板标签。也就是说，如果你客户的网站内容是一条条 CMS 记录，直接导出 zip 是无法把全部文章页面都变成独立 HTML 的。再加上 Webflow 官方老版本导出里有 webfont.js、normalize.css、webflow.css，新版可能又有自己的打包方式，你拿到手的第一件事其实是“体检”，而不是盲目清理。

所以我通常把官方 Export 包当底料：先不要急着改 HTML，把整个解压目录放到本地服务器里浏览一遍，打开控制台看哪些资源来自外域、哪些脚本报错、哪些内容没有渲染出来。这个浏览动作决定了后面清理的边界，否则你连哪里该删都不知道。体检完了，再做资源本地化和代码瘦身。

2.2 Framer：先发布成线上页面，再做静态化

Framer 没有官方 HTML 导出包，这意味着要拿到可部署代码，就得换一条路线：先把站点发布到一个可访问的地址，然后用能执行 JavaScript 的工具去抓取并“落地”成静态页面。这里说的抓取不是浏览器右键“另存为”，而是通过 Playwright、Puppeteer 这类无头浏览器打开每一个 URL，等待脚本执行完、动画走完、懒加载图片出现后，再把当前 DOM 保存成 HTML。

为什么不能直接右键另存为？因为 Framer 页面里大量样式和状态是由 JS 在浏览器运行时生成的。右键保存往往只能拿到首屏的一部分，滚动不到的区域图片可能还是懒加载占位图；预加载进 CSS 的字体可能不在 HTML 标记里。无头抓取可以设置一个标准视口宽度、禁用或模拟网络、强制等待几秒，让页面把绝大多数可视内容渲染出来，然后再保存，这样抓到的 HTML 才相对完整。

Framer 站点的响应式比较复杂，移动端布局可能是通过 JS 判断视口后动态切换的。静态化抓取时，我建议至少用 1440×900 和 390×844 两种视口各抓一遍，否则交付出来的版本只适配桌面端，手机上一看就是坏的。这一点是很多第一次做 Framer 静态化的人最容易漏掉的细节。

2.3 为什么不能直接拿生成后的 HTML 上线

有人会觉得，既然无头浏览器已经把页面 DOM 拿到了，那这些 HTML 直接放进服务器不就行了？不一定。无头浏览器保存的 HTML 只是某个时间点的结果，里面有很多资源 URL 仍然指向 framerusercontent.com 这类平台域名。域名如果不续费或被平台清理，图片就断了。

另一个问题是运行时脚本。Framer 的动画、交互、懒加载都依赖它自己的 runtime，这份运行时脚本可能达到几百 KB，而且里面有一些对平台 API 的调用。客户服务器如果没有对应环境，某些交互会在控制台里报错。因此静态化后还要做一轮“去平台化”：把平台 CDN 上的图片、视频、字体下载到本地，把外链脚本要么保留但确认无害、要么替换成轻量的本地实现。

同样，Webflow 导出包里有些 class 规则也依赖平台的 CSS 结构，比如隐藏移动端菜单的 w-nav 按钮、展开下拉菜单等，都需要 webflow.js 配合。如果去掉脚本想省体积，交互就没了。所以平台和交付 HTML 之间永远有一层“翻译”，没有谁能做到点击一个按钮就有完美结果。

3. Webflow 站点导出成 HTML 的实操过程

3.1 导出前，先把动态内容和动态功能“压平”

如果你的 Webflow 站点用了 CMS 动态列表，这一步必须提前处理。我遇到过一个客户网站，首页有个“行业资讯”区域，后台录了几十条文章，列表是 Webflow CMS Collection List。严格讲，这种动态列表是“模板 + 数据”的组合，如果想交给客户跑静态服务器，数据必须在构建时变成文章 HTML。

实际操作中，我会先把 CMS 内容通过 Webflow 后台导出一份 JSON 或 CSV，然后写一段简单的脚本把数据填到 HTML 模板里，生成静态 HTML。或者更省事一点，直接在 Webflow 设计器里把首页动态列表改成静态内容块，再在 CMS 里手动粘贴关键内容。这种方式适合内容量不大、以后不再高频更新的小站。如果内容很多，建议放弃“导出 HTML”这个思路，还是让客户继续用 Webflow 托管，或者迁移到一套静态站点生成器。

表单也要注意。Webflow 的表单默认会把数据提交到 Webflow 的后台。导出 HTML 后，如果还保留原来的 action，用户填了表单，数据其实仍是发给 Webflow 的。客户如果断了平台服务，这表就废了。因此静态交付前，要么把表单换成第三方的表单服务地址，要么告诉客户这里不再收集数据。这个坑不会让页面显示报错，但会在业务真正跑起来时出大问题，所以处理干净比想象中重要。

3.2 Export 包拿到手后的体检清单

用 Webflow 导出 zip 后，我会先创建一个专门的工作目录，例如 site-clean/，把解压后的原始代码拷进去。然后打开 index.html，不用代码编辑器，而是用浏览器拖到本地服务里看，配合开发者工具做三项检查：

第一项，检查 Console 有没有红色错误。Webflow 站点的老代码里经常出现 WebFont.load 之类调用，如果字体脚本指向 Google Fonts 而本地环境没网，控制台会报加载失败。第二项，打开 Network 面板，把所有请求按域名分组，凡是发到 webflow.com、googleapis.com 等外部域名的请求都要登记下来。第三项，手动点击页面里的导航按钮、折叠面板、Tab 切换，看哪些交互能正常触发、哪些只有样式没有行为。

把这些结果列成一张“待处理事项表”，比直接埋头改代码高效得多。我在处理实际项目时，会根据排查结果决定哪部分 CSS 可以整段裁掉，哪些 JS 需要保留但把地址改为本地，哪些功能需要砍掉。注意，不要一看脚本标签上写着 jquery.min.js 就想删：Webflow 早期很多交互是基于 jQuery 的，你删了以后菜单都无法打开，必须先试删再完整点一遍页面。

3.3 资源本地化：字体、图片、CSS 与 JS 的路径重写

Webflow Export 包里常见一批外部请求，比如 Google Fonts 的 woff2 文件、平台 CDN 上的 JS 文件。把外部资源变成本地文件是干净化中最机械也最关键的一部分。

字体我习惯手动处理：从 Google Fonts 或 Webflow 的字体设置里找到实际使用的 font-family，下载对应字重的 WOFF2 文件，放进 assets/fonts/，然后在 CSS 开头或单独 fonts.css 里写 @font-face。有的人会直接在浏览器控制台里看到 woff2 请求，就把 URL 复制下来下载，这个方法也可以，但要注意文件可能按 unicode-range 拆分，一个字体族会下载十几份分片，只挑一个文件不够。最稳妥的是去字体源站选好字重和字符子集再下载完整文件。

图片处理相对直接。如果 Webflow 的图片在 zip 里已经是本地文件，那只要检查 HTML 里的 src 是否用相对路径。如果图片是外域地址，用脚本解析出所有图片 URL，逐个下载到 images/ 目录，再把 HTML 里的 src 替换成新路径。不要漏掉 CSS background-image 里的 url，Network 面板里类型为 img 的请求都要记下来。CSS 和 JS 的外部引用也可以同样处理：把 .css、.js 下载到本地，把 <link> 和 <script> 的 src 改成相对路径。

3.4 清理 class 和注释的边界线

很多教程会让你用工具删除未使用的 CSS class，但 Webflow 的 class 情况特殊：HTML 里有些 class 是配合 JS 做动态切换的，表面上“没用到”，实际上脚本会在某个状态添加它。比如 w--redirected-from-top、w--redirected-to-bottom 这类 class，是 Webflow 导航组件运行逻辑的一部分。如果你用 PurgeCSS 把这些 class 全删掉，可能页面某个滚动静音就出问题了。

我的处理原则是：保留所有以 w- 开头且和组件逻辑相关的 class，只删除那些纯视觉且明显可以合并的冗余包装。另外，HTML 里的大段注释可以删，但 CSS 文件里的分区块注释建议保留，比如“Navbar Section”“Footer Section”，这样客户拿到后能大致分清哪儿是哪儿。别为了“干净”把所有注释删到光，那反而会让后续维护变难。

清理完后，建议运行一次压缩工具让代码整体保持整洁：

bash复制npx html-minifier-terser \
  --collapse-whitespace \
  --remove-comments \
  --minify-css true \
  --minify-js true \
  index.html -o index.clean.html

这里不是强制压缩到一行，而是说明清理流程可以借助成熟工具完成。实际交付时我更推荐保留良好的缩进结构，方便客户或研发团队阅读，不一定追求体积最小。

4. Framer 站点静态化的实操流程

4.1 抓取前要做好的准备

Framer 站点静态化前，需要先确认最终发布域名打开是正常的。如果设置了密码保护，先临时打开访问权限；如果站点有 CMS 动态路由，要提前整理好 URL 列表，因为无头浏览器没法爬出一个“动态数据库”里不存在的链接。

然后建议把桌面端断点下的字体、动效检查一遍。Framer 对动画依赖比较重，抓取时脚本如果没有执行完成，页面的 opacity 可能还是 0，你会得到一个“所有内容都透明但实际存在”的空页面。等待策略不能只是等待 DOMContentLoaded，最好等待网络空闲后再额外延迟 2 秒，让入场动画把元素放在最终可见状态。

我遇到过一个坑：页面有自动播放的轮播图，动画循环不断发起新的 rAF，导致 networkidle0 迟迟不来。这就要给 goto 设置超时，或者采用“先等 8 秒，再强制保存”的策略。抓取工具不是万能药，很多细节需要根据具体页面情况微调。

4.2 一次抓取多个页面的脚本骨架

这里用 Playwright 写一个能用的小脚本，思路是：给定一个起始 URL，从首页里解析出所有站内链接，再逐个访问并保存 HTML。完整的抓取还包含资源下载，但下面只展示页面落地部分：

bash复制mkdir -p framer-static/raw

在 framer-static/ 目录初始化 Node 项目并安装 playwright：

bash复制npm init -y
npm install playwright

然后保存一个 snapshot.js：

js复制const { chromium } = require('playwright');
const fs = require('fs');
const path = require('path');

const BASE_URL = 'https://your-site.framer.app/';
const OUTPUT_DIR = path.join(__dirname, 'raw');

function sleep(ms) {
  return new Promise(resolve => setTimeout(resolve, ms));
}

// 从 HTML 中解析同源页面链接
function extractLinks(html, base) {
  const links = new Set();
  const regex = /href=["']([^"']+)["']/g;
  let match;
  while ((match = regex.exec(html)) !== null) {
    const href = match[1];
    if (href.startsWith('http') && href.startsWith(base)) {
      links.add(href);
    } else if (href.startsWith('/')) {
      links.add(new URL(href, base).href);
    }
  }
  return [...links];
}

(async () => {
  fs.mkdirSync(OUTPUT_DIR, { recursive: true });
  const browser = await chromium.launch();

  const page = await browser.newPage({ viewport: { width: 1440, height: 900 } });

  const visited = new Set();
  const queue = [BASE_URL];

  while (queue.length > 0) {
    const url = queue.shift();
    if (visited.has(url)) continue;
    visited.add(url);

    console.log('正在抓取:', url);
    try {
      const response = await page.goto(url, {
        waitUntil: 'domcontentloaded',
        timeout: 60000
      });
      if (!response || !response.ok()) continue;

      // Framer 的动画和懒加载需要时间
      await sleep(3000);

      const html = await page.content();
      const parsed = new URL(url);
      const fileName = parsed.pathname === '/' ? 'index' : parsed.pathname.replace(/\//g, '_');
      fs.writeFileSync(path.join(OUTPUT_DIR, fileName + '.html'), html);

      const links = extractLinks(html, BASE_URL);
      for (const link of links) {
        if (!visited.has(link)) queue.push(link);
      }
    } catch (err) {
      console.error('抓取失败:', url, err.message);
    }
  }

  await browser.close();
})();

这段脚本没有做到生产级，但它能把页面入口文件全部落地。真正静态化时还要在拿到 HTML 后，下载 HTML 里的图片、CSS、JS，并把 URL 改成相对路径。我一般会用类似 cheerio 的库解析 HTML DOM，遍历所有 img[src]、link[href]、script[src]，而不是用正则替换，这样不会误伤模板字符串或注释里的地址。

注意：无头浏览器抓取行为是否符合站点使用条款，需要自己判断。本文默认你抓的是自己搭建或有权限处理的站点。

4.3 Framer 图片和字体怎么从平台 CDN 迁到本地

Framer 图片地址通常带 framerusercontent.com 域，直接放在静态交付包里极不优雅。你需要先把这些 URL 原样下载下来，生成一份本地文件，再重新拼接。我习惯在抓取 HTML 之后写一个资源同步脚本。

逻辑大概是：用 cheerio 读取每个 HTML 里的 img、source、link[rel="preload"]、CSS 里的 url(...)，把远程地址统一收集到一个 Set，然后逐一用 fetch 下载到 assets/ 目录。文件命名建议使用原 URL 的哈希或最后一段文件名，避免同名覆盖。下载完成后，再把 HTML 和 CSS 里的 URL 字符串替换成相对路径。注意区分大小写，图片扩展名可能是 .webp、.png，同时有些 URL 带查询参数，比如 ?q=80，下载时要去掉参数但替换时要保留完整协议才能定位。

字体方面，Framer 大部分站点会预加载字体文件到浏览器里，Network 面板里能看到 WOFF2 请求。把这些文件保存下来后，建议在 CSS 中检查有没有对应的 @font-face 声明，并确保 font-family 名称一致。不要只下载文件不更新 CSS，否则页面仍会去请求平台域名。

4.4 哪些 Framer 交互可以留，哪些必须换

Framer 的页面动效由自身运行时实现，完全剔除脚本后，元素可能会停留在一个不可见的初始状态，或者按钮点击后没有任何反馈。想真正静态化，一个可行的策略是按页面需求保留最小交互实现。

导航菜单是最常见的保留项。桌面端导航如果是普通链接跳转，那不需要 JS；移动端菜单如果是一个点击展开的面板，可以自己写一段十几行的小脚本，替换 Framer runtime。锚点平滑滚动同理，用 CSS scroll-behavior: smooth 就能解决，没必要引入大运行时。而一些复杂的手势轮播、滚动驱动视差、鼠标跟随特效，在静态代码中保留的性价比很低，要么删除要么降级成普通渐显。

我建议清理前先把页面功能列成表，逐个标“线上必须 / 有更好 / 没有也行”，然后只保留“线上必须”的那部分。干净 HTML 不等于一个像素都不能少，先确保客户最关心的内容和表单可用，再谈动效。否则为一段 3 秒动画引入 200KB 平台脚本，反而违背了交付干净 HTML 的本意。

5. 把整套流程固化成一键导出脚本

5.1 自动化前，想清楚你的“一键”到底覆盖到什么范围

所谓一键导出，不可能是“写一个脚本，把任何 Webflow/Framer 站点都瞬间变成纯手写 HTML”。更合理的定义是：针对一个已选定的站点，把前面所有手工做过的清理动作固化下来，下一次遇到同类站点能复用。

所以我会建议大家先完整手工跑一遍流程，同时记下每个动作的输入输出。哪些 URL 需要下载，哪些 class 需要删除，哪些页面属于动态路由必须列表抓取。记完以后，你会发现流程里机械重复的部分很多：下载图片、替换链接、重写字体路径、删除指定脚本标签、压缩 HTML。这些动作适合代码化，而“判断哪个脚本能删、哪个动画要降级”这类决策，仍然需要人来决定。

5.2 一个最小但要健壮的资源本地化脚本

下面用 Node 做最小示意，重点不是把代码跑通，而是告诉你资源本地化到底在做什么。我会先用 cheerio 打开每个 HTML 文件，然后遍历元素并下载远程资源。

js复制const fs = require('fs');
const path = require('path');
const cheerio = require('cheerio');
const { downloadAsset } = require('./downloader');

const RAW_DIR = path.join(__dirname, 'raw');

async function processHtml(filePath) {
  const html = fs.readFileSync(filePath, 'utf8');
  const $ = cheerio.load(html);

  const remoteUrls = [];

  $('img[src^="http"]').each((_, el) => {
    remoteUrls.push($(el).attr('src'));
  });

  $('script[src^="http"]').each((_, el) => {
    remoteUrls.push($(el).attr('src'));
  });

  $('link[href^="http"]').each((_, el) => {
    remoteUrls.push($(el).attr('href'));
  });

  for (const url of remoteUrls) {
    const localPath = await downloadAsset(url);
    // 把远程 URL 替换为相对路径
    $(`[src="${url}"], [href="${url}"]`).each((_, el) => {
      $(el).attr($(el).attr('src') ? 'src' : 'href', localPath);
    });
  }

  fs.writeFileSync(filePath, $.html());
}

实际操作远比这个复杂，比如可能 CSS 里引用远程字体、同 URL 有不同查询参数、video poster 属性里的地址。但核心逻辑就是这样：把“需要外部域名请求”的资源全部换成“本地相对路径”。跑完脚本后，我会用浏览器开发者工具再过一遍，理论上 Network 面板不应再出现平台域名请求。

5.3 脚本输出目录结构建议

一键脚本跑完后，我建议最终交付目录长这样：

text复制dist/
├── index.html
├── about.html
├── css/
│   ├── main.clean.css
│   └── fonts.css
├── js/
│   ├── nav.js
│   └── smooth-scroll.js
├── assets/
│   ├── fonts/
│   ├── images/
│   └── videos/
└── README.txt

README.txt 里写清楚三件事：这个站点是怎么导出的、哪些页面需要联网才能完整显示、以后如果要在本地编辑应该改哪个文件。这个文件不是为了凑数，而是客户或接手的技术看到后不会一头雾水。我见过太多交付包里没有任何说明，过三个月连项目方自己都忘了哪个 JS 是干嘛的。

5.4 自动化和人工检查如何配合

脚本能省时间，但我不建议完全信任脚本的产出。每次跑完一键流程，至少做一轮人工回归。站点一旦有成百上千张图片，下载过程中难免遇到超时或文件名冲突；自动替换路径时，也有可能误伤原本就是本地的相对路径。所以我会在脚本最后输出一份“资源检查报告”，列出所有下载失败和替换猜测异常的项目，然后人工打开页面一件件确认。

我的做法是启动本地静态服务器：

bash复制cd dist
python3 -m http.server 8080

然后打开 http://localhost:8080，逐个页面点过去。不要直接双击本地文件，因为 file 协议下，某些浏览器会限制脚本或字体加载，导致出现“本地明明能用，部署到线上却坏了”的误判。用 http.server 能更接近线上真实行为，同时还能避免因为跨域策略导致的干扰。

6. 常见问题与排查技巧实录

6.1 五类高频问题速查

表格里的问题几乎每个人都会撞上至少一个。看见“本地打开样式错乱”，不要先怀疑清理步骤，先看是不是网络请求被断掉导致的。我用开发者工具看 Network 面板，凡是有红色 404 请求，优先解决；然后再看 Console 报错，最后才去调 CSS 规则。

6.2 为什么 Webflow 的动态列表导出后是空壳

如果你发现首页有列表区域，但导出的 HTML 里只看到类似 <div class="w-dyn-list"><div class="w-dyn-empty"> 这样的空状态，说明动态内容没有跟着 Export 进入静态页。Webflow 的动态列表本质上是一个数据库查询结果，Export 只导出模板，并不包含后台全部数据。

处理办法前面提过：要么把内容手动固化成静态 HTML，适合内容少的官网；要么用 Webflow CMS 导出内容后再构建。对于后者，你如果会一点 Node，完全可以写一个脚本把导出的 JSON 循环填充到动态列表模板里。前提是模板区域里的 HTML 结构已经存在，只是少了数据节点。

6.3 直接双击 HTML 和部署到服务器的差异

很多人会觉得“我双击打开能看，那放服务器肯定没问题”。实际上，file 协议和 http 协议对资源加载的限制不一样。Webflow 生成的一些字体会用 fetch 加载，file 协议下可能因为 CORS 被浏览器拦截；有的 JS 里通过 window.location 生成路径，在不同协议下也会异常。

这也是为什么我反复强调要在本地起一个静态服务器做最终验收。这里有个便宜又实用的技巧，在目录里跑 npx serve 或 python3 -m http.server 都行，如果交付时客户不熟悉命令行，你也可以直接把整个文件夹压缩发过去，附上 README 写清楚“打开 index.html 前先运行一下这个命令”，或者直接部署到对象存储后给客户一个线上预览地址。这样能防止客户拿本地 file 方式误判。

7. 最后分享一点我的交付习惯

我处理完 Webflow/Framer 静态化后，不会立刻把 zip 发过去，而是会额外花十分钟做两件事。第一，把导出的每个 HTML 文件都在 W3C 校验工具里过一次，主要看有没有明显的标签不闭合问题；第二，把导航里每个链接都用脚本扫一遍，确认没有指向原平台后台的残留链接。

另外我越来越觉得，干净 HTML 交付的核心价值不在于“把所有平台前缀去掉”，而在于让客户拥有自主权。Webflow 和 Framer 本身是很好的设计工具，但客户如果不想继续被平台绑定，那么一套能离线运行、能在任何服务器上托管的 HTML/CSS/JS 文件才是真正属于他的资产。处理这类需求的过程中，把平台运行时留下的依赖层层剥离，本质是在帮客户做一次“资产确权”。所以每次交付我都会跟客户多沟通一句：以后如果要改页面内容，最好保留一份原始工程，直接在能可视化编辑的编辑器里改，不要每次都找我手工清理。这个建议也送给所有正在看这篇内容的朋友，学会导出清理很重要，但你最终的目标，是让站点持续可维护，而不是永远靠“一键”去救火。