企业官网建设流程全解析

同样的页面摆在我面前，我想抄它的配色和间距风格，但每次都是肉眼对着截图取色、拿尺子量间距，效率低到怀疑人生。后来我认真研究了一件事：直接抓取网站上某个元素的 DOM 结构，再用浏览器提供的计算样式能力，把字体、颜色、圆角、边距一次全读出来，最后自动整理成一份 DESIGN.md 设计规范文档。整个过程不需要设计文件，也不需要设计师手工标注，完全靠前端技术栈就能完成。

这个思路合适谁？如果你是前端开发、需要做竞品风格分析的从业者，或者想把自己网站的视觉元素沉淀成一套可维护的设计规范，这篇文章应该能帮你省下大量时间。下面我把拆解思路、实操方法和踩过的坑一次讲清楚。

1. 内容整体设计与思路拆解

1.1 为什么从 DOM 而不是设计稿入手

常规思路是拿到 Sketch、Figma 源文件再提取样式，但现实里你大概率拿不到别人的源文件，更多场景是：看到一个页面觉得“这个风格很适合我们产品”，希望快速复用它背后的视觉规律。这时候 DOM 反而是最可靠的“设计稿”，因为浏览器最终渲染什么效果，完全取决于 DOM 结构和计算样式的结果。

DOM 里能看到元素的层级关系：哪些是卡片、哪些是按钮、哪些是文字容器。每个节点上挂载的 class 和 inline style，又直接对应到具体的 CSS 规则。把这些节点和样式抓下来，就等于拿到了“反编译后的视觉层源码”。

1.2 计算样式在设计提取中的角色

很多人会直接读element.style，这只能拿到内联样式，真正决定视觉表现的是 class 对应的样式表规则，经过浏览器级联计算后的最终值。举例来说，某个按钮的字体大小可能是继承自父容器，而不是按钮本身显式声明了font-size: 14px。只看element.style会得到空字符串，但通过getComputedStyle就能拿到真实的 14px。

计算样式是浏览器“说了算”的最终值，包括：

• 颜色值会被统一成 rgb/rgba 格式，方便后续二次处理
• 长度单位会换算成 px，宽高、边距、字体大小这些参数可比性很强
• 继承属性会被展开，不需要自己逐级向上查找

这就让自动化提取具有了可行性。你不需要去分析那些分散在各处的 CSS 文件，也不用关心是 Less、Sass 还是纯 CSS 写的，最终落到浏览器的计算值是一致的。

1.3 DESIGN.md 的定位与设计

DESIGN.md 是一份用 Markdown 记录的设计规范文档。与设计系统中的 Storybook 文档不同，它不需要维护成本，可以随抓取脚本即时生成。我的思路是把文档拆分成三个区块：

• 色彩体系：主色、辅助色、文本色、边框色的具体色值
• 排版规范：字体族、字号梯度、行高、字重
• 圆角与间距：按钮圆角、卡片圆角、内边距、外边距

这份文档既是给自己团队的沉淀，也能作为前端变量定义的参考。你甚至可以把它放到项目仓库里，每次改版后重新抓取一次，让文档和真实页面保持同步。

2. 环境准备与基础工具选择

2.1 抓取方案的取舍：浏览器控制台 vs Node.js 脚本

设计提取有两种常见的执行环境，先说结论：如果只抓单个页面且不想搭环境，浏览器控制台最方便；如果要批量抓取一组页面并自动生成文档，建议用 Node.js + Puppeteer。

我建议至少先掌握浏览器控制台的方案，这能把整套逻辑跑通，后面要扩展成自动化脚本时，代码改动非常小。因为核心的提取逻辑其实就是那几行 DOM 查询和计算样式读取函数，把这段逻辑换到 Node 环境里也只是替换掉document的获取方式。

2.2 快速用 Puppeteer 把网站跑起来

用 Puppeteer 的目的很简单，就是模拟浏览器打开目标页面，等页面加载完成后执行我们的提取脚本。以提取某个文档站的设计风格为例，基础启动代码也就二十几行：

const puppeteer = require('puppeteer'); (async () => { const browser = await puppeteer.launch({ headless: 'new' }); const page = await browser.newPage(); await page.setViewport({ width: 1440, height: 900 }); await page.goto('https://example.com/docs', { waitUntil: 'networkidle2', timeout: 30000 }); // 后续的提取逻辑写在这里 await browser.close(); })();

启动浏览器时我会把headless设为new模式，这是无头浏览器的新实现，渲染效果和完整浏览器基本一致，而且跑一些现代 CSS 特性也不容易出问题。networkidle2表示等待网络连接数不超过 2 个时认为页面加载完成，对于字体文件、异步渲染的场景比较稳。

2.3 识别页面中值得提取的样本元素

这一步最需要人是思考，代码只是工具。你要先判断页面上哪些元素真正代表了设计风格。我常用的方法是按组件类型分组，从每一类里挑 1 到 3 个代表性元素：

• 导航栏链接：看字体、字号、用色
• 主按钮/次按钮：看背景色、边框圆角、文字颜色、内边距
• 卡片容器：看背景、圆角、阴影
• 正文段落与标题：看字体族、行高、字重、字号
• 表单输入框：看边框色、聚焦色（聚焦色需模拟交互）

我会给这些元素加上临时标记style-guide-marker，后续脚本统一获取。加上标记是为了精确定位，避免把整个页面所有元素全部拉下来造成数据爆炸。

3. 核心细节解析与实操要点

3.1 精确锚定 DOM 节点

提取的第一步是先把目标元素从页面里找出来。如果你已经在控制台手动选好了元素，可以直接用document.querySelector加自定义属性来标记；如果想更省事，直接在 Elements 面板右键选择 Copy → Copy selector，也能得到精确选择器。

某些框架站点（比如 React、Vue）会在 class 名里带哈希后缀，比如_button_abc123_5，这种选择器不稳定，下次构建就会变。更好的方案是找稳定的语义化标签或属性，比如[role="button"]、[data-component="Button"]这类选择器，或者直接对 aria-label 做匹配。

写代码时要注意，页面里可能有多个相同类型的元素，比如多个主要按钮，此时取第一个还是取平均？我建议取页面上视觉权重最高的那个，通常是首页首屏里的大按钮。如果粒度想更细，可以把匹配到的所有同类元素都取出来再做统计，不过这是后话。

3.2 一行代码读取计算样式

用浏览器原生 API 读取计算样式，代码非常简洁：

const btn = document.querySelector('[data-component="Button"]'); const styles = window.getComputedStyle(btn); const designToken = { backgroundColor: styles.backgroundColor, color: styles.color, fontSize: styles.fontSize, fontWeight: styles.fontWeight, borderRadius: styles.borderRadius, padding: styles.padding, lineHeight: styles.lineHeight, fontFamily: styles.fontFamily, }; console.log(JSON.stringify(designToken, null, 2));

这里最核心的就是window.getComputedStyle这个接口。调用后返回的是一个实时的CSSStyleDeclaration对象，可以像读对象属性一样读取样式。需要注意返回结果里有很多属性是浏览器自动补充的默认值，所以提取时一定要按我们关心的字段白名单来，不要无脑遍历所有属性。

颜色值会被规范成rgb(255, 0, 0)这样的格式，如果原 CSS 里有透明度，则会返回rgba(255, 0, 0, 0.5)。字体相关属性比如font可能会被拆成独立的font-family、font-size、font-weight，这些都是计算后的最终级联结果。

3.3 颜色规范与去重处理

一次抓取往往得到几十个颜色值，直接塞进文档会显得杂乱无章，而且很多颜色是重复的或者只有细微差别。我在实操中会在脚本里加一步颜色归类和排序：

function normalizeColor(colorStr) { const canvas = document.createElement('canvas'); canvas.width = 1; canvas.height = 1; const ctx = canvas.getContext('2d'); ctx.fillStyle = colorStr; ctx.fillRect(0, 0, 1, 1); const [r, g, b, a] = ctx.getImageData(0, 0, 1, 1).data; return { r, g, b, a: a / 255 }; }

这个方法的原理是利用 Canvas 的 2D 上下文把所有 CSS 颜色格式统一解析成 rgba 数值。不管是 hex、rgb、hsl 还是命名的颜色，它都能正确处理。拿到数值后就可以自己控制精度，比如相近的颜色可以归到同一个分组里。

整理文档时，我会按出现频度排序，高频颜色排在前面。把主色、辅助色区分出来，这部分人工判断仍然不可少，但机器已经把候选范围缩小了。

3.4 字体与排版类属性的收集策略

排版信息的提取相对稳定，字体大小、行高、字重都在计算样式里有直接对应的字段。这里有一个容易踩的坑：中文字体栈在计算样式里会返回一长串候选字体列表。比如设置了font-family: "PingFang SC", "Microsoft YaHei", sans-serif，返回的值会带上引号和逗号。

如果设计文档里只需要“品牌字体”，我会取字体列表的前 1-2 项，同时注意去掉通用兜底字体。字体大小建议单独收集，不要用复合写法里的font属性，因为复合属性可能因为某项是默认值而省略部分信息。行高如果单位是像素，计算样式会返回带 px 的值；如果是无单位值，返回的是数字加空字符串，比如1.5。做统计表时可以统一换算成数值。

4. 实操过程与自动化生成 DESIGN.md

4.1 开取自选元素的完整编写步骤

我建议直接在浏览器控制台完成一次小规模验证。步骤是这样的：

1. 打开目标网站，按 F12 进入开发者工具
2. 在 Console 面板粘贴以下封装函数
3. 页面里选择你要提取的元素，比如登录页的按钮，调用函数提取

function extractStyle(selector) { const el = document.querySelector(selector); if (!el) { console.warn('没有找到元素', selector); return null; } const cs = getComputedStyle(el); const props = [ 'background-color', 'color', 'border-color', 'border-radius', 'font-size', 'font-weight', 'line-height', 'font-family', 'padding-top', 'padding-right', 'padding-bottom', 'padding-left', 'margin-top', 'margin-bottom' ]; const result = {}; props.forEach(p => { result[p] = cs.getPropertyValue(p); }); result.text = el.textContent.trim().slice(0, 30); return result; } console.table(extractStyle('button.signup'));

getPropertyValue的好处是可以直接用连字符格式的属性名，和 CSS 里的写法一致，不需要转成驼峰。控制台输出的表格也直观，适合快速核对。

4.2 在页面内一键生成 DESIGN.md

当所有核心样式都收集齐全后，下一步是把这些值组织成 Markdown 文档。这段脚本我也是直接在浏览器控制台跑的，它会从页面上预先标记好的样本元素中采集，然后生成文本：

function generateDesignMd() { const els = document.querySelectorAll('.style-guide-marker'); if (els.length === 0) { return '没有找到任何带标记 .style-guide-marker 的元素'; } const sections = { colors: [], typography: [], others: [] }; els.forEach(el => { const cs = getComputedStyle(el); const role = el.getAttribute('data-role') || 'element'; if (role === 'button' || role === 'card') { sections.colors.push(`- **${role} 背景**: ${cs.backgroundColor}`); sections.colors.push(`- **${role} 边框**: ${cs.borderColor}`); sections.others.push(`- **${role} 圆角**: ${cs.borderRadius}`); sections.others.push(`- **${role} 内边距**: ${cs.padding}`); } if (role === 'heading' || role === 'text') { sections.typography.push(`- **${role} 字号**: ${cs.fontSize}`); sections.typography.push(`- **${role} 行高**: ${cs.lineHeight}`); sections.typography.push(`- **${role} 字重**: ${cs.fontWeight}`); } }); const header = ['# DESIGN.md', '', '> 本文件由页面样式提取脚本自动生成，生成时间：' + new Date().toISOString(), '']; const colorSection = ['## 颜色体系', ''].concat(sections.colors); const typeSection = ['## 字体排版', ''].concat(sections.typography); const otherSection = ['## 布局细节', ''].concat(sections.others); return header.concat(colorSection, typeSection, otherSection).join('\n'); }

为了方便复制，可以在脚本里再加一行console.log(generateDesignMd())，然后在控制台右键选择 Copy 把完整结果保存下来。这份文档就是一份能直接提交到仓库里的基础设计规范，虽然还不像专业设计系统的文档那么完整，但作为起步版本已经足够清晰。

4.3 在 Node 环境中把整站跑完整

前面只是单页验证，实际要系统性地分析一个网站，用 Puppeteer 更合适。这里我给出可以整站运行的踩坑版完整脚本思路：

const puppeteer = require('puppeteer'); const fs = require('fs'); async function extractPageStyles(page) { return page.evaluate(() => { function getStyles(el) { const cs = getComputedStyle(el); return { bg: cs.backgroundColor, textColor: cs.color, borderColor: cs.borderColor, radius: cs.borderRadius, fontSize: cs.fontSize, lineHeight: cs.lineHeight, padding: cs.padding, }; } const targets = []; // 用相对稳定的选择器找页面关键元素 const mainBtn = document.querySelector('.btn-primary') || document.querySelector('[type="submit"]'); const navLink = document.querySelector('nav a'); const card = document.querySelector('.card'); const heading = document.querySelector('h1, h2'); const paragraph = document.querySelector('p'); if (mainBtn) targets.push({ role: '主按钮', element: mainBtn }); if (navLink) targets.push({ role: '导航链接', element: navLink }); if (card) targets.push({ role: '卡片', element: card }); if (heading) targets.push({ role: '标题', element: heading }); if (paragraph) targets.push({ role: '正文', element: paragraph }); return targets.map(t => ({ role: t.role, text: t.element.textContent.trim().slice(0, 30), styles: getStyles(t.element) })); }); } (async () => { const browser = await puppeteer.launch({ headless: 'new' }); const page = await browser.newPage(); await page.goto('https://target-site.com', { waitUntil: 'networkidle2' }); const data = await extractPageStyles(page); fs.writeFileSync('./extracted-styles.json', JSON.stringify(data, null, 2)); await browser.close(); })();

脚本里所有页面相关的选择器都写在一个函数里，后面如果要调整也容易维护。对每个目标元素的判断都很宽松，找不到就跳过，不阻塞整站采集。

4.4 把抓取结果加工成多页面的一致规范

单页面的数据只是快照，多个页面的数据放一起后，你会看到同一个按钮在不同页面的样式可能略有偏差，比如有的地方间距被调过，有的地方颜色老版本没有更新。规范文档的意义就在于暴露出这种不一致性。

我的处理方法是把所有页面抓到的同一类元素放进数组里，然后做频率统计。比如按钮背景色出现最多的那个值，就是实际主色；边框圆角如果集中在 4px 和 8px 两档，说明设计有明确的层级区分，而不是随意取值。

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

5.1 getComputedStyle 返回的值带单位，怎么统一处理

计算结果里长度值都带 px，比如16px，而部分属性返回的是auto或normal，比如宽度可能返回789px，行高可能返回normal。直接手工整理时容易漏掉这些细节。我的经验是先写一个简单的值清洗函数：

function parsePx(value) { const match = value.match(/^([\d.]+)px$/); return match ? Number(match[1]) : null; }

这样既能判断一个值是否是有效的像素值，也能把纯数字提取出来用于后续统计。对于返回normal或auto的属性，就不用当作有效像素来处理，文档里可以标注“默认值”。

5.2 背景颜色读出来是 transparent，但视觉上确实有颜色

遇到这种问题通常是因为颜色作用在父元素的伪元素或者背景图片上，比如按钮有一层渐变或者半透明遮罩。你说的没错，按钮视觉上确实有颜色，但计算样式里背景色就是 transparent，因为真正的颜色来自background-image。

排查时就把background-image、box-shadow也一起打印出来看。如果按钮背景是渐变，background-color可能只是兜底色，真正风格要读渐变终止颜色。遇到背景图的情况，可能还需要额外截一张图，人工补录主色调。

5.3 页面字体用了 web font，导致文字区域为空

抓取时如果过早执行脚本，字体还没加载完成，某些只包含字体图标的图标按钮读出来全是空白。文字类元素的 textContent 也可能为空或者只包含空格，导致样式提取时看不出来元素的作用。

解决方式是预留足够的加载等待时间，或者监听字体加载完成事件。我在 puppeteer 里常用document.fonts.ready，通过page.evaluate等待这个 Promise 完成，能确保 Web Font 准备好了再采集。

await page.evaluate(() => document.fonts.ready);

5.4 常见问题速查表

整理了提取过程中最常碰到的几个问题，方便大家直接查阅：

5.5 提取过程中的避坑心得

在深色模式下抓取时，读出来的颜色是浅色主题的变量，这是个隐形坑。多数现代网站的暗色模式通过prefers-color-scheme或根节点 class 切换，抓取前可以用脚本强制设置根节点的color-scheme: light，避免误采到暗色变量。

另一个经验是：不要只抓一个页面就下结论。至少抓首页 + 一个二级页面 + 一个内容详情页，把三份数据交叉对比后再生成文档，这样得到的色彩和字号梯度才真正有代表性。

最后一个建议：对所有提取的值，要保留元素的可读文本与用途标记。否则两个月后回来你会对着rgba(66, 133, 244, 1)发呆，完全想不起这是哪个按钮的颜色。带用途标注的文档才有长期使用的价值。

6. 更高阶的玩法：把 DESIGN.md 转化成前端变量

做完整套提取流程，我发现最有价值的延伸方向是：把 DESIGN.md 里保持下来的规律映射成 CSS 自定义属性（变量）。色彩和圆角命名清晰后，在组件代码里直接引入变量，整个项目的视觉迭代就方便多了。

最基本的映射方式是这样，把提取出来的色值写进:root：

:root { --color-primary: #4285f4; --color-bg-card: #ffffff; --radius-md: 8px; --text-font-size: 16px; }

如果目标框架是 React + styled-components，也可以生成对应的 JS 常量文件。把 DESIGN.md 当中间产物，前后端都能从中拿到需要的变量，这是这个方案结构化收益最大的环节。

实际操作中我通常先在控制台跑通提取逻辑，再把逻辑封装到公司内部的 CLI 工具里。团队其他人只需要执行一条npm run style:extract -- --url https://站点地址就能拿到一份新的规范文档，上手成本降到最低。把这个流程固定下来以后，我基本告别了对着截图猜颜色的日子，你也可以直接抄这套方案去试一下。