企业官网建设流程全解析

先说个实际的场景。前阵子有个朋友找我，说他在某个文档分享站的网页端看中了一份自己参与整理的技术手册，但那个站点没有现成的“导出Word”按钮，复制粘贴又因为分页和动态加载搞得稀碎。他问我有没有什么办法把这堆网页内容整理成一份干净的本地方档。我一开始也懒得搞，毕竟这类需求网上一搜全是各种“神器”，但真正靠谱的没几个。后来想着自己动手写个小工具，前后花了两个多小时搞出来，顺手把思路和踩过的坑都记下来，这篇就把整个方案完整拆开讲一遍。

注意，我这里讨论的是“网页正文提取与文档生成”这套通用技术，整个实验过程也是围绕我自己上传到平台上的公开内容来做的。你在使用任何类似技术时，请一定确认内容的使用权限，不要拿这套东西去碰别人的付费和受限内容。技术本身是中性的，但用途得把握好。

1. 整体思路拆解：为什么要同时用JS脚本和Python

这个需求拆开来看，其实包含了两层任务。第一层是把网页里的正文内容完整、准确地捞出来；第二层是把捞出来的内容按标题层级、段落、图片这些结构，重新排版成一份Word文档。这两层任务的技术特点完全不同，用一个工具硬啃到底往往会很难受。

先看第一层“捞内容”。很多文档平台的内容并不是老老实实写在HTML源码里的，而是通过JavaScript动态渲染到页面上的。你用常规的HTTP请求去抓，拿到手的可能只是一个空壳框架，真正的正文根本不在里面。就算内容是静态的，分页、懒加载、折叠展开这些机制也会让纯脚本抓取变得非常麻烦。

再看第二层“生成Word”。这个活儿用浏览器里的JavaScript来做就很别扭。虽然也能拼字符串，但要处理样式、标题级别、表格结构、图片，代码量会非常难看，而且不好复用。而Python那边有现成的库，比如BeautifulSoup做解析，python-docx做Word生成，各管一段，代码结构会清晰很多。

所以我的整体策略是这样的：

1. 用浏览器控制台里的JS脚本，利用浏览器这个“免费渲染引擎”，把动态加载的页面内容完整展开，再从DOM中提取结构化文本。
2. 把提取到的结果保存成中间文件（txt或JSON）。
3. 用Python读取这个中间文件，做清洗、结构化解析，最后用python-docx输出成Word。

这套方案的巧妙之处在于：把“浏览器才能搞定的动态渲染问题”留在浏览器里解决，把“文档排版这种Python擅长的事情”交给Python。两边都只做自己擅长的事，逻辑顺、代码量小。如果你只用一个工具硬扛，要么得学Selenium这种重型自动化框架，要么得在JS里手写文档排版，都是给自己找麻烦。

1.1 前端JS脚本在这条链路里的角色

JS脚本的作用不是做最终排版，而是做一个“内容收割机”。它的目标只有一个：拿到完整、干净、带结构信息的正文文本。

为什么在浏览器控制台里做提取会比用脚本直接抓靠谱？因为浏览器已经把页面彻底渲染完了。那些需要滚动加载的内容、等待接口返回的数据，都已经在DOM树里成为现实存在的节点。你写那几行提取脚本的时候，面对的是“结果”，而不是“过程”。

这就好比你要从一栋楼里搬家具，不需要自己搭脚手架一层层往上爬，因为电梯已经把你送到楼层了。浏览器就是这架电梯。你的JS脚本只需要在楼层里把家具搬出来，不用关心电梯怎么运行。

而且，用控制台还有一个隐性好处：请求接口时，浏览器天然带上了完整的登录态、Cookie和请求头信息。你不需要在Python脚本里艰难地模拟登录状态，因为你的浏览器本身就处于已登录状态。很多新手卡在“明明浏览器能看到内容，代码就是抓不到”这个坎上，本质上就是没利用好这一点。

1.2 Python脚本在这条链路里的角色

Python脚本是整个流水线的“加工车间”。它拿到JS脚本输出的纯文本或者JSON之后，要做的事情很清晰。

首先是清洗。网页提取出来的文本往往带着各种噪声：页脚的版权信息、侧栏的推荐栏、多余的空格和空白字符。Python用字符串处理和正则表达式，可以快速把这些垃圾信息筛掉。

其次是结构化。我让JS脚本在提取的时候保留一定的结构线索，比如用连续两个换行表示新段落，用#号标记标题级别。Python这边就可以根据这些约定，把纯文本重新拆分成标题、段落、列表项，形成一个Python的数据结构，比如字典列表。

最后是生成Word。python-docx这个库专门用来创建和修改Word文档，支持设置标题样式、正文字体、表格、图片嵌入等。你不需要懂Word内部的文件格式，只需要按Python对象的方式操作就行。

1.3 什么场景下其实只需要一个工具

如果你遇到的是一个纯静态页面，正文直接在HTML源码里，那么Python一把梭就够。直接requests拿HTML，然后BeautifulSoup解析，不需要经过JS脚本那一层。相反，如果只是临时一两页内容，也不用大动干戈上Python，直接在浏览器控制台里跑一段JS，把结果复制出来手动排版就行。

最怕的就是静态动态傻傻分不清，一上来就在浏览器控制台里猛敲代码，结果发现页面是纯静态的，你多绕了一大圈。反过来也一样，如果页面是纯JS动态渲染的，你还在Python那边苦苦尝试各种模拟方案，那性价比就太低了。所以动手之前，先花五分钟搞清页面的渲染方式，比什么都重要。

2. 动手前的关键准备：先搞清页面是怎么渲染的

任何网页提取项目，第一步都是分析页面。这一步如果偷懒，后面会花更多时间填坑。我个人的习惯是：打开开发者工具，先在“源码”和“Elements”两个面板之间来回切换，确认我要提取的内容到底存不存在于原始HTML中。

2.1 判断内容是静态还是动态的三分钟方法

方法很简单。在页面里找到一段你肉眼可见的正文文字，打开开发者工具的“View Source”或者Network里的初始HTML响应，按Ctrl+F搜索这段文字。如果能搜到，说明内容是服务端直接返回的，属于静态渲染；如果搜不到，那就说明内容是浏览器执行JavaScript之后才生成的，属于动态渲染。

我用这个法子测过好几个平台。有的平台首页能看到内容摘要，但点进详情页后正文全是空的，等页面加载完才出现内容。这种就属于典型的动态渲染，用Python直接请求只会拿到页面骨架。而有些老旧的文档站，正文直接写在HTML里，一眼就能搜到，省事很多。

2.2 找到正文的“容器”

动态渲染的页面，最终的正文一定挂在某个DOM节点下面。你需要在Elements面板里找到这个节点。操作方法是：在页面正文上点击右键，选择“检查”，然后看Elements面板里高亮的那个元素。如果那个元素只是某个段落，就往上找它的父节点，一直找到那个“包含整篇正文，但又不包含侧栏和页脚”的容器节点。

找到之后，记录这个节点的特点。比如它的id是什么、class是什么，是有规律还是随机生成。有些平台的class名带着版本号或者时间戳，每次发布都变，这种就不适合写死在代码里。更好的办法是用DOM结构特点来判断，比如“某个div下面连续多个h2和p”这样的结构特征。

这里有个非常容易踩的坑：你以为找到了正文容器，结果一执行提取，发现把文章底部的“相关推荐”也捞进来了。这种情况很常见，因为很多页面的正文容器和推荐位在DOM层级上是兄弟节点，你选错了一个层级就会把不想捞的也带出来。我的经验是，先看一下容器下有多少子节点，再对比页面实际显示的内容，确认多一个节点少一个节点对应页面上哪一块。

2.3 分页、懒加载与“阅读全文”按钮

在线文档平台几乎没有一打开就全篇呈现的。最常见的三种加载方式，我分别说一下处理思路。

第一种是滚动懒加载。就是你往下滚，内容一段一段蹦出来。这种情况，你需要先模拟滚动到底部，让所有内容加载完成，再执行提取脚本。我用过的方法是在控制台里执行一个循环滚动指令，每次往下移动一个屏幕的高度，然后等待一两秒，直到页面高度不再变化。

第二种是假分页。页面底部有“第1页/第5页”这样的分页按钮，点击后内容切换。这种最坑，因为每一页的URL可能是一样的，内容是通过接口动态更新的。处理办法是把每一页都打开，重复执行提取，最后把结果拼接起来。

第三种是“阅读全文”折叠按钮。这个相对好办，找到按钮然后调用DOM的click事件，让折叠区展开就行。不过在点击之后要稍微等一等，因为展开的动作可能触发新的异步请求，等请求完成了，内容才会真正出现在DOM里。

2.4 工具选型：浏览器和Python库就这么定

浏览器方面，我用的是日常开发用的Chrome，按F12就能进控制台。Firefox的开发者工具也可以，操作基本一致。逻辑上没有特殊要求，现代浏览器都行。

Python这边，我用的库有三个：requests负责发起网络请求，BeautifulSoup（配合lxml解析器）负责解析HTML，python-docx负责生成Word。如果只是处理JS脚本导出的文本，连requests和BeautifulSoup都不太用得上，只需要python-docx一个库就够了。

这里给你们一个非常实用的建议：别一上来就装一堆重型库。先想清楚自己要走哪条路，再决定要哪些工具。我见过有人为了一个文本提取需求，把Pandas、Selenium、Scrapy全装了，最后全没用上，环境还搞得一团糟。

3. 实操：控制台JS脚本提取网页正文

这一段是整个方案中技术含量最高的一环，也是让你打开浏览器就能立刻看到效果的一环。我在这一步踩过的坑最多，写出来希望你们能绕开。

3.1 第一步：先确认选择器能不能命中目标

不要一上来就写几十行脚本。先在控制台里跑一行最简单的命令，确认你的选择器能选到正文容器：

// 在控制台里执行，替换成你实际页面中正文容器的选择器 const container = document.querySelector('.doc-content'); console.log(container);

如果输出null，说明选择器没匹配到。这时候不要急着改选择器，先回Elements面板确认一下容器的实际特征。如果输出的是一个节点对象，说明已经拿到了。再进一步，用代码检查一下这个容器的高度和子节点数量：

const container = document.querySelector('.doc-content'); console.log(container.scrollHeight, container.childElementCount);

这两个数字能帮你判断内容是否完整。如果高度明显小于页面实际高度，说明还有内容没加载出来，先不要继续。

我做实验的时候，第一次执行就把容器选错了，那个类名同时出现在页头导航和正文两个地方，document.querySelector只选中了第一个，导致后面导出的内容全是导航菜单的文字。所以这一步宁可多花两分钟确认，也别急着往下写。

3.2 完整提取脚本：递归遍历DOM结构

选好容器之后，脚本的核心逻辑就是一个递归函数。它要做的事情可以概括成这几点：跳过style、script、noscript这些无意义节点；遇到块级元素就补一个换行标记；遇到文本节点就把文字内容拼出来；遇到图片节点就记录图片地址；遇到标题标签就加上层级符号。

下面是我在控制台里用的脚本核心逻辑：

function extractNode(node) { // 跳过无意义标签 if (['STYLE', 'SCRIPT', 'NOSCRIPT'].includes(node.tagName)) return ''; // 文本节点直接返回文本内容，并去掉首尾空白 if (node.nodeType === Node.TEXT_NODE) { return (node.textContent || '').trim(); } // 图片节点返回占位符和图片地址 if (node.tagName === 'IMG') { return `\n[图片:${node.src}]\n`; } // 标题标签，附加层级标记 if (/^H[1-6]$/.test(node.tagName)) { const level = node.tagName.slice(1); return `\n<${level}>` + Array.from(node.childNodes).map(extractNode).join('') + `</${level}>\n`; } // 其他元素，递归处理子节点 const result = Array.from(node.childNodes).map(extractNode).filter(text => text.length > 0); // 如果是块级元素，在元素前后补换行 const blockTags = ['P', 'DIV', 'LI', 'TR', 'TABLE', 'SECTION', 'ARTICLE']; return blockTags.includes(node.tagName) ? '\n' + result.join('') + '\n' : result.join(''); } // 执行提取，第三个参数是你在上一步确认的正文容器 const result = extractNode(document.querySelector('.doc-content')); // 在控制台打印结果开头部分，先检查效果 console.log(result.slice(0, 200));

这个脚本的关键在于递归：每个元素节点都会遍历自己的所有子节点，把文本一层层捞上来。文本节点之间原本没有换行，是靠块级元素的补换行逻辑，把段落结构完整保留下来。

我在写这个脚本的时候，一开始没有处理blockTags，结果整篇文章所有段落全挤在一行里，完全没法用。加上块级元素换行之后，结构才勉强可读。后来又加了标题标签的层级标记，这样Python那边才能识别出一级二级标题。

3.3 把结果带出浏览器：copy命令比手动选择靠谱得多

控制台把结果打印出来之后，你当然可以手动选择复制。但结果很长的时候，手动选择效率很低，还可能因为控制台的显示截断而丢失内容。这里用浏览器的copy函数就好用得多。

copy(extractNode(document.querySelector('.doc-content')));

执行完这条命令，提取结果就已经在你的剪贴板里了。你只需要新建一个文本文件，粘贴进去，保存即可。我做实验时，把结果粘贴到VS Code里，顺便再观察一下有没有明显的格式问题。如果你是准备用Python来生成Word，建议保存成带结构标记的文本文件就行，比如我这里保留的<1>、<2>这种标题层级标记。

3.4 表格内容的提取优化

普通文本内容按上面的脚本处理基本够用了，但表格是个例外。原因很简单：表格是一个二维结构，光靠加换行符拼成文本，行列关系就全丢了。这个坑我是在处理一份包含对比表格的文档时踩到的。

解决办法是：判断节点是否属于表格范围内，如果是，就换一套提取逻辑。这里给出一个针对table的专门处理思路：

function extractTable(tableNode) { const rows = tableNode.querySelectorAll('tr'); return Array.from(rows).map(row => { const cells = row.querySelectorAll('td, th'); return Array.from(cells).map(cell => cell.textContent.trim()).join('\t'); }).join('\n'); }

这段代码会把每个单元格的内容取出来，同一行之间用制表符分隔，不同行之间用换行分隔。这样处理之后，表格内容虽然变成了纯文本，但行列结构还保留着，Python那边拿到之后，可以根据制表符的数量恢复成二维数组，再写入Word表格。

4. 实操：Python解析HTML并生成Word

如果页面是静态的，或者你已经通过JS脚本导出文本，Python这边主要做两件事：解析内容、生成Word。如果页面是静态的，那么requests抓HTML、BeautifulSoup解析，一步到位；如果页面是动态的，那就先跳过抓取步骤，直接读取JS脚本导出的文本。

4.1 静态页面怎么请求HTML

先用requests把页面拿下来。这里有两个细节必须注意。

第一个是请求头。有些平台会检查请求是不是来自正常浏览器，直接裸请求会被拒。最简单的办法是设置User-Agent，把它伪装成Chrome浏览器。第二个是编码。很多平台的中文页面用的是gbk编码，直接拿response.text可能会导致乱码。解决方法是先读二进制，再统一按Unicode转换：

import requests headers = { "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36" } resp = requests.get(url, headers=headers) resp.encoding = resp.apparent_encoding # 让requests根据页面内容自动判断编码 html = resp.text

这里用resp.apparent_encoding要比直接拿resp.encoding稳妥得多。我当时直接抓回来乱码成一片，设了这行之后问题瞬间解决。

4.2 静态页面的正文提取

拿到HTML之后，用BeautifulSoup定位正文容器：

from bs4 import BeautifulSoup soup = BeautifulSoup(html, "lxml") content = soup.select_one(".doc-content") # 换成实际页面的选择器

然后遍历正文容器下的节点，按层级提取：

def parse_content(node): result = [] for child in node.children: if child.name is None: continue if child.name in ["h1", "h2", "h3", "h4"]: level = child.name[1] result.append({"type": "heading", "level": int(level), "text": child.get_text(strip=True)}) elif child.name == "p": result.append({"type": "paragraph", "text": child.get_text(strip=True)}) elif child.name == "table": result.append({"type": "table", "rows": parse_table(child)}) return result

这里把内容组织成一个个字典，每个字典“type”字段标明是标题、段落还是表格，这样后面生成Word的时候可以分门别类地处理。这种结构化的中间格式，比直接拼成一段字符串要灵活得多，因为你可以随时调整某一种类型的处理逻辑，而不影响其他类型。

4.3 用python-docx生成Word

python-docx用法简单，核心就三步：创建Document对象，往里面添加段落或者标题，设置样式。下面这个函数可以把上面解析出来的结构化内容写成Word：

from docx import Document from docx.shared import Pt def build_word(data, output_path): doc = Document() # 设置默认字体，处理中文显示 style = doc.styles["Normal"] style.font.name = "宋体" style.font.size = Pt(12) for item in data: if item["type"] == "heading": level = item["level"] doc.add_heading(item["text"], level=level) elif item["type"] == "paragraph": doc.add_paragraph(item["text"]) elif item["type"] == "table": rows_data = item["rows"] table = doc.add_table(rows=len(rows_data), cols=len(rows_data[0])) for i, row in enumerate(rows_data): for j, cell in enumerate(row): table.cell(i, j).text = cell doc.save(output_path)

这里需要注意一点：如果中文显示异常，多数情况是字体设置的问题。Word默认的Calibri字体对中文支持不好，把Normal样式的字体设置为宋体，基本能解决大部分中文乱码或显示异常的问题。

表格写入时，我默认用第一行数据的长度作为列数。如果表格的行列数不一致，这里会报错。所以要么在写入前排错，要么在遍历的时候动态判断行数，确保每行长度一致。

4.4 动态页面怎么衔接JS脚本的输出

如果你的页面是动态渲染的，走的是JS脚本提取这条路，那Python这边就很简单了。直接读取之前保存的文本文件，然后根据我在JS脚本里定义的标记规则，重新解析成结构化数据。

比如我的中间文件长这样：

<1>第一章 环境准备<1> 每个段落文字... <2>1.1 安装依赖<2> ...

Python解析的时候，可以用正则把<1>、<2>这些标记找出来，按标题处理；其他不带标记的行按段落处理。这样就能复用上面那个build_word函数。

什么情况下可以更快一点？如果内容量不大，我又不想写解析函数，直接在文本文件里用简单规则手动标注，然后让Python按规则渲染。我实际操作下来，对于一篇一万字左右的文档，整个流程从JS提取到Word输出，大概只需要两分钟。

5. 踩坑记录：问题与排查速查表

任何一个网页提取项目，坑都集中在几个固定区域。我把实际操作中遇到的问题整理成一张速查表，你们可以直接对照排查。

接下来我针对几个高频问题展开讲讲。

5.1 乱码问题：记住这一行就够了

这个问题出现的频率极高，但解决办法翻来覆去就这么几个。requests默认会用headers里的charset判断编码，但不少老平台的页面根本不会在响应头里写清楚编码，或者写的和实际不一致。这时候用apparent_encoding让requests根据页面内容特征推断，基本能救回来。

如果你是在控制台JS提取文本，乱码问题几乎不会出现，因为浏览器已经帮你在页面渲染层面解决了编码的问题。所以乱码这个坑主要发生在纯Python请求的路径上。

5.2 内容不全：先动手前再动手

这个问题我在前面提过多次，你们一定要养成一个习惯：提取之前，先让页面所有内容加载完成。我的操作顺序是这样的，先滚动：

// 滚动到页面底部，触发懒加载 async function scrollToBottom() { let currentHeight = document.body.scrollHeight; while (currentHeight < document.body.scrollHeight || currentHeight === 0) { window.scrollTo(0, document.body.scrollHeight); await new Promise(r => setTimeout(r, 800)); if (document.body.scrollHeight === currentHeight && currentHeight > 0) break; currentHeight = document.body.scrollHeight; } } await scrollToBottom();

这段代码每隔800毫秒滚动到底部一次，直到页面高度不再变化为止。脚本执行完之后，再运行提取脚本。我在实验时，如果省略这一步，只能拿到整篇文章大约30%的内容，而执行滚动后能拿全。

5.3 请求被拒：关注请求头，更关注速度

如果你用Python直接抓页面，拿到403，最常见的原因是缺少请求头，或者请求频率太高。请求头的处理在4.1里已经说过了。频率控制这条我想多说一句：很多平台的服务器虽然有防护，但真正让服务器感到压力的不是单次请求，而是短时间内的密集请求。

稳妥的做法是，每抓一页就睡眠一两秒。抓十页以上，每页之间睡眠五秒。这不是技术问题，是基本礼仪。你的目标是拿自己要的内容，没必要把对方的服务器拖垮，更没必要让自己被拉黑。

5.4 图片和表格丢失：分别定制处理

图片和表格堪称文本提取的“重灾区”。图片问题在于：表格问题在于：普通文本提取逻辑把行列结构抹平了。解决办法前面已经分别给出，这里不再重复，只强调一句：如果你要处理的文档带大量图表，建议在JS提取阶段就分别定制处理逻辑，别用通用文本提取一把抓，否则后面返工的代价更大。

5.5 动态页面还要用Python怎么办

前面讲的都是“JS提取 + Python生成”或者“Python请求静态页面”这两种路径。如果动态页面非要全程用Python，也不是不行，最常规的方案是用Selenium或Playwright驱动一个无头浏览器，让浏览器帮你执行JS再抓取。但我要说句实在话：对一个偶尔处理几篇文档的需求来说，方案成本太高了。装浏览器驱动、处理版本匹配、维护选择器，这些时间足够你手动跑十次“JS复制粘贴”方案了。

所以，先用简单的方案验证够不够，不够再上重武器。大多数场景下，两种方案结合已经足够。

6. 版权、合规与“文明爬虫”的基本原则

这个部分我放到最后，但分量绝对不能轻。网页内容提取是一门非常实用的技术，但正因为实用，才更需要搞清楚边界。

6.1 什么情况下做这件事是没问题的

我把安安稳稳的使用场景总结成这几类：处理自己上传的文档；处理已经获得作者明确授权的文档；处理平台声明允许下载、且内容不受版权限制的文档；把文档下载用于个人学习、研究，且不进行任何商业传播。

我自己的实验就是从“我自己上传到平台的文档”开始的。这既验证了流程可行性，又完全踏在安全边界内。建议你们也这么做：想练手，就用自己的内容练，别拿别人的版权内容当小白鼠。

6.2 红线绝对不能碰

以下几类行为我明确不建议：绕过付费机制或会员限制来获取本应付费的内容；批量抓取他人版权内容并进行二次分发；用爬来的内容做自己的付费课程、付费文档；对平台服务器进行高频请求、压测或绕过风控。

你在网上看到的各种“下载某文库文档”的现成脚本，绝大多数都在触碰这些红线。这类脚本可能短期内能用，但用的人随时面临账号封禁甚至更严重的风险。技术学到手是本事，用歪了是事故。

6.3 一个负责任的爬虫该有的基本礼仪

如果你决定用Python抓网页，给自己定几条规矩。第一，先看看这个站有没有robots.txt，尊重对方的爬虫规则。第二，控制频率，宁可慢一分，不要快一秒。第三，只拿自己需要的字段，不要整个数据库Dump下来。第四，设置合理的请求头，不要伪装成乱七八糟的来源，堂堂正正表明自己是一个正常的浏览器请求。

这些不是空话，而是我自己踩过坑之后的体会。以前我图快，几秒钟并发抓了几十个页面，结果IP被临时封禁，反而耽误了更多时间。慢一点，礼貌一点，技术上可能反而更顺畅。

6.4 演示流程：一个合规的自测步骤

这里说一下我自己做实验时的完整自测流程，你们可以照抄。第一步，找一个允许上传内容的文档平台。第二步，上传一篇自己写的、不涉密的文章。第三步，在浏览器中打开自己上传的文档。第四步，用开发者工具跑JS提取脚本。第五步，用Python生成Word。第六步，对照原文档检查提取效果。

这样一套流程下来，你既完整验证了技术方案，又毫无版权风险。练熟了这套流程，以后遇到真正有授权的文档要整理，无非就是把“自己上传的内容”换成“有授权使用的内容”，技术逻辑完全不变。

我在这个项目里最后沉淀下来的，其实不只是那几段脚本代码，而是一套“处理任何网页正文提取需求”的工作思路。再遇到类似需求，我第一反应就是先判断页面静态还是动态，然后选择“JS+Python”还是“纯Python”，这两个分支想清楚了，剩下都是体力活。

再分享一个小技巧：遇到任何新页面，先别急着写提取代码，而是花五分钟看看网络面板和Elements面板，搞清楚内容的来源和结构。这五分钟基本能帮你节省后面一小时的调试时间。项目本身不算复杂，但“先分析再动手”这个习惯，价值比任何代码都大。