陌念念接“能不能直接把整站代码给我”这类需求，我几乎每个月都要处理一次。客户拿着 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 丢给客户，客户打开发现样式全乱，最后反过来说是网站没做好。所以不要想“反正文件能打开就行”，接到这种需求第一件事，先问清楚这份代码后续给谁用、放哪里跑，再决定动手深度。这个前置沟通能省掉后面一堆因为场景不清导致的返工。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
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 这类无头浏览器打开