企业官网建设流程全解析

1. 这不是“爬虫教程”，而是一套可落地的内容归档工作流

你有没有过这样的时刻：看到知乎上一篇讲「时间管理底层逻辑」的专栏，写得特别扎实，但手机刷着刷着就滑走了；雪球里某位资深投资者连续三个月更新的行业分析，想存下来慢慢读，结果发现网页版排版混乱、图片加载失败；微博上一个摄影博主发的胶片拍摄教程，附了十几张高清样片和参数设置，点开大图保存一张张太费劲——更别说那些带字幕的竖屏教学视频，根本没法离线看。这些内容散落在不同平台，格式不一、结构各异，靠手动收藏、截图、复制粘贴，三天都整理不完。我试过用浏览器插件批量保存网页，结果知乎的回答里公式渲染错乱、雪球的表格变成乱码、微博视频只下到封面图。后来干脆自己搭了一套自动化归档系统，核心目标很朴素：把多平台的优质内容，按原始结构+可读格式+元数据完整地存进本地硬盘，不求实时同步，但求随时能翻、能检索、能复用。它不涉及任何账号登录、不绕过平台反爬机制、不抓取用户隐私数据，只处理公开可访问的内容，本质是“网页快照+结构化导出”的组合方案。适合内容创作者做素材库、研究者建文献集、学生攒学习资料，或者单纯想摆脱信息焦虑的普通人。整套流程用 Python 脚本驱动，依赖开源工具链，所有代码可查、逻辑透明、配置自由，关键步骤我都做了参数级注释，哪怕你只懂基础命令行，照着文档也能跑通。

2. 整体设计思路：分层解耦 + 格式适配 + 元数据保全

2.1 为什么放弃“万能爬虫”，选择“平台定制化采集”

很多人第一反应是写个通用爬虫，用一个脚本通吃所有平台。我踩过这个坑：知乎的专栏文章嵌套在 React 渲染的 SPA 里，直接请求 HTML 拿不到正文；雪球的财报分析页用 WebAssembly 解析 PDF 表格，服务端渲染时 JS 不执行；微博的视频地址是动态生成的，需要模拟点击行为才能触发。强行用一套 selector 规则去匹配，维护成本极高——今天知乎改个 class 名，整个流程就崩。所以最终方案是分平台定制采集器，每个平台单独封装一个模块，核心逻辑只有三件事：

• 定位内容源：明确要抓什么（比如知乎专栏的某篇文章 ID、雪球某篇帖子的 URL、微博某条动态的 mid）；
• 解析结构化数据：提取标题、作者、发布时间、正文文本、图片列表、视频链接、附件 URL 等字段；
• 生成标准化输出：统一转成 Markdown + 附件文件夹的格式，附带 JSON 元数据文件。

这样做的好处是：某个平台接口变动，只需改对应模块，不影响其他平台；每个模块可以独立测试、调试、升级；后续新增小红书、豆瓣等平台，只要加一个新模块就行，架构零侵入。就像修车，不是拿一把万能扳手硬拧，而是为每个螺丝配专用工具。

2.2 格式选择逻辑：为什么是 Markdown + 附件 + JSON，而不是 PDF 或数据库

导出格式直接决定后期使用效率。我对比过几种方案：

• 纯 PDF：看起来“正式”，但搜索困难（PDF 文字识别不准）、无法版本管理（改一个字就得重生成整个 PDF）、图片缩放失真、无法嵌入代码块或数学公式；
• 数据库存储：适合高频查询，但普通人没数据库运维能力，导出再导入又是一道坎，且丢失原始排版语义；
• HTML 单文件：保留样式，但跨平台兼容性差（微信里打不开、Notion 导入格式错乱）、体积臃肿（内联 CSS/JS 占大量空间）。

最终选定Markdown + 附件文件夹 + JSON 元数据的组合，理由很实在：

• Markdown 是程序员、作家、研究员的通用语言，VS Code、Obsidian、Typora 都原生支持，手机 App 也能流畅阅读；
• 图片、视频、PDF 附件单独存放，方便用 Everything 快速搜索、用系统预览图浏览、用 ffmpeg 批量转码；
• JSON 文件记录发布时间、原始 URL、作者昵称、标签等元数据，既可用于脚本自动分类（比如按“AI”“投资”“摄影”打标签），也能导入到 Notion 数据库做可视化看板。

举个实际例子：下载微博一条带 5 张图+1 个 30 秒视频的教程，最终生成：

weibo_4982736451238765/ ├── content.md # Markdown 正文，含图片相对路径 ![](images/1.jpg) ├── images/ # 存放 5 张原图，命名 1.jpg ~ 5.jpg ├── video.mp4 # 下载的视频文件 └── metadata.json # { "url": "https://weibo.com/...", "author": "摄影老张", "timestamp": "2024-03-15T14:22:00Z", "tags": ["胶片", "曝光"] }

这种结构，双击content.md就能在 Typora 里看到图文混排效果，进images/文件夹就能批量重命名，打开metadata.json就能一眼看清来源——比 PDF 好用十倍。

2.3 元数据保全策略：为什么连“发布时间”都要精确到秒

很多人导出内容只关心正文，忽略元数据。但实操中，元数据才是长期价值的关键。比如：

• 知乎回答的发布时间，决定了观点是否过时（2020 年谈“区块链应用”和 2024 年谈，技术背景天差地别）；
• 雪球文章的作者认证信息（是否持证分析师、历史预测准确率），影响内容可信度判断；
• 微博视频的原始分辨率（1080p 还是 720p），关系到后期剪辑能否放大不模糊。

所以我的元数据字段设计遵循“最小必要原则”：只存对后续使用有明确价值的字段，避免冗余。每个平台的 JSON 结构都不同，但核心字段统一：

• source_url：原始页面 URL，用于溯源和跳转；
• fetched_at：本地下载时间戳（ISO 8601 格式），记录“我是什么时候存下它的”；
• published_at：内容发布原始时间（从网页 DOM 或 API 中解析），用于按时间轴排序；
• author：作者名称或 ID，知乎存“张伟（认证人工智能工程师）”，雪球存“@价值捕手（前券商首席）”，微博存“摄影老张（金V）”；
• platform：平台标识符（zhihu/snowball/weibo），方便脚本批量筛选。

提示：published_at字段必须从网页源码中解析，不能用fetched_at替代。我见过太多人导出后才发现，所有内容的“发布时间”都是下载当天，导致按时间排序完全失效。知乎的发布时间藏在<meta property="article:published_time" content="2024-02-10T08:30:00+08:00">里，雪球在<script>标签的 JSON 数据中，微博则需解析created_at字段并转换时区——这些细节，后面实操环节会逐个拆解。

3. 核心细节解析与实操要点：从 URL 到本地文件的完整链路

3.1 知乎专栏文章下载：绕过 SSR 渲染陷阱，精准提取富文本

知乎专栏文章最大的坑是服务端渲染（SSR）不完整。你用 requests 请求文章 URL，返回的 HTML 里正文区域是空的<div id="root"></div>，因为真实内容由前端 JS 动态注入。很多教程教用 Selenium 模拟浏览器，但太重——启动 Chrome 实例要 3 秒，下载 100 篇文章就得等 5 分钟。我的方案是逆向分析知乎的 API 接口，直接获取结构化数据。

知乎专栏文章的 API 地址规律是：

https://www.zhihu.com/api/v4/columns/{column_id}/posts/{post_id}

其中column_id是专栏 ID（如zhihu-daily），post_id是文章 ID（URL 最后一串数字）。但这个接口需要x-zse-96和x-zse-93两个加密 header，直接调用会 403。破解方法是：用浏览器开发者工具抓包，找到知乎 JS 文件中window._zse96函数，用 Python 复现其逻辑。我已将该算法封装成独立函数（见 GitHub 仓库zhihu_zse96.py），输入post_id和column_id，输出合法 header。

提取到 JSON 数据后，正文在content字段，但它是 HTML 格式，含大量<p><img><code>标签。直接存 HTML 不利于后续处理，所以要用html2text库转 Markdown：

import html2text h = html2text.HTML2Text() h.ignore_links = False h.body_width = 0 # 不自动换行 markdown_text = h.handle(json_data['content'])

关键参数body_width=0必须设为 0，否则长代码块会被截断换行，破坏可读性。另外，知乎的图片 URL 是相对路径（如/pic/xxx.jpg），需拼接成绝对 URLhttps://zhimg.com/pic/xxx.jpg，并在 Markdown 中替换为相对路径![](images/xxx.jpg)，最后下载图片到images/子目录。

注意：知乎对频繁请求有限流，单 IP 每分钟最多 30 次。我在脚本中加入time.sleep(2)，每请求一次停 2 秒，实测下来稳定不被封。如果要加速，可用代理池，但普通用户没必要——每天下载 50 篇，花 100 分钟，换回可离线阅读的资料，值。

3.2 雪球文章下载：解析动态表格与 PDF 附件，保留原始数据精度

雪球的文章难点在于财务数据表格和 PDF 附件。很多分析文章会嵌入 Excel 表格截图，但真正有价值的是背后的原始数据。雪球的解决方案是：在文章末尾提供 PDF 下载链接，里面是可复制的表格。我的脚本会自动识别这类链接（正则匹配https://xueqiu.com/.*?\.pdf），下载 PDF 后用PyPDF2提取文字，再用pandas读取表格。

但 PDF 表格识别常出错。比如“2023年营收”列被识别成“2023 年营收 ”（多空格），或数字“1,234.56”变成“1 234.56”。我的修复逻辑是：

• 用re.sub(r'\s+', ' ', text)统一空格；
• 用pandas.read_csv(StringIO(text), sep=r'\s{2,}', engine='python')按多空格分割列；
• 对数字列，用pd.to_numeric(col.str.replace(r'[^\d.-]', '', regex=True), errors='coerce')提取纯数字。

对于非 PDF 的纯文本表格（雪球常用<table>标签），用pandas.read_html()直接解析，比手动写 selector 稳定得多。解析后的表格存为 CSV 文件，与 Markdown 正文同名（如snowball_123456.csv），在 Markdown 中用[查看原始表格](snowball_123456.csv)链接。

实操心得：雪球的 API 比知乎友好，无需加密 header，但需在请求头中带上User-Agent和Cookie（至少包含xq_a_token，从浏览器复制即可）。Cookie 过期后脚本会报 401，此时手动更新一次，比逆向加密简单太多。

3.3 微博内容下载：应对反爬 UA 检测与视频分段下载

微博的反爬重点在User-Agent 检测和视频分段。直接用默认 UA 请求，返回 403；用常见浏览器 UA，又可能被识别为爬虫。我的方案是：

• 从 fake-useragent 库随机取一个 UA，每次请求都换；
• 加Accept-Language: zh-CN,zh;q=0.9和Referer: https://weibo.com/，模拟真实用户行为。

微博视频是最大难点。它不提供直链，而是返回一个 M3U8 播放列表，里面是分段的 TS 文件（如seg-1.ts,seg-2.ts）。下载逻辑分三步：

1. 用requests获取 M3U8 文件内容；
2. 用正则提取所有seg-\d+\.ts的 URL；
3. 用ffmpeg合并 TS 文件：ffmpeg -i "concat:seg-1.ts|seg-2.ts|..." -c copy output.mp4。

但 TS 文件可能有防盗链，需在requests中带上Cookie和Referer。我的脚本会自动从微博页面 HTML 中提取XSRF-TOKEN和SUBCookie，并附加到 TS 请求头中。合并时用-c copy参数，不重新编码，保证画质无损、速度快（100MB 视频合并只要 3 秒）。

注意：微博图片下载要区分“原图”和“缩略图”。URL 中含large的是原图（如https://wx4.sinaimg.cn/large/xxx.jpg），含bmiddle的是缩略图。脚本会优先下载large链接，若 404 再降级到bmiddle，确保图片质量。

4. 实操过程与核心环节实现：从零开始搭建你的归档系统

4.1 环境准备与依赖安装：5 分钟完成初始化

整个系统基于 Python 3.8+，无需虚拟环境（避免新手配置麻烦），所有依赖用 pip 一键安装。打开终端，依次执行：

# 安装核心库 pip install requests beautifulsoup4 html2text pandas PyPDF2 fake-useragent lxml # 安装 ffmpeg（视频处理必需） # macOS（用 Homebrew） brew install ffmpeg # Windows（下载官网二进制，加到 PATH） # https://www.gyan.dev/ffmpeg/builds/ # Ubuntu/Debian sudo apt update && sudo apt install ffmpeg

关键点说明：

• lxml是 BeautifulSoup 的高速解析器，比内置html.parser快 3 倍，尤其处理知乎长文章时明显；
• fake-useragent会自动从在线数据库获取 UA，首次运行需联网，后续缓存到本地；
• PyPDF2专攻 PDF 文字提取，比pdfplumber轻量，对雪球的简单 PDF 足够用。

提示：Windows 用户安装lxml可能报错，直接用pip install lxml‑4.9.3‑cp39‑cp39‑win_amd64.whl（从 Christoph Gohlke 的页面 下载对应版本），比编译源码省事。

4.2 配置文件编写：用 YAML 管理多平台参数

所有平台的配置集中在一个config.yaml文件，结构清晰，修改方便。示例：

zhihu: column_id: "zhihu-daily" post_ids: [123456, 234567, 345678] # 要下载的文章 ID 列表 output_dir: "./zhihu_archive" snowball: urls: - "https://xueqiu.com/1234567890/123456789" - "https://xueqiu.com/0987654321/987654321" output_dir: "./snowball_archive" weibo: mids: ["4982736451238765", "4982736451238766"] # 微博动态的 mid output_dir: "./weibo_archive" global: timeout: 30 max_retries: 3 delay_between_requests: 2

脚本启动时读取此文件，自动分发任务。新增知乎文章，只需在post_ids里加 ID；新增雪球链接，往urls列表里塞 URL——不用改代码，降低维护门槛。

4.3 核心脚本执行：一条命令启动全流程

主脚本archive_runner.py是整个系统的入口，执行逻辑如下：

if __name__ == "__main__": config = load_config("config.yaml") # 并行处理各平台（用 concurrent.futures） with ProcessPoolExecutor(max_workers=3) as executor: futures = [] if config.get('zhihu'): futures.append(executor.submit(download_zhihu, config['zhihu'])) if config.get('snowball'): futures.append(executor.submit(download_snowball, config['snowball'])) if config.get('weibo'): futures.append(executor.submit(download_weibo, config['weibo'])) # 等待全部完成 for future in as_completed(futures): result = future.result() print(f"✅ {result['platform']} 完成，共下载 {result['count']} 篇")

运行命令：

python archive_runner.py

输出示例：

✅ zhihu 完成，共下载 3 篇 ✅ snowball 完成，共下载 2 篇 ✅ weibo 完成，共下载 2 篇 📁 归档完成！查看 ./zhihu_archive/ 等目录

每个平台模块独立，失败互不影响。比如微博下载超时，知乎和雪球仍正常运行，错误日志会写入error.log，方便排查。

4.4 输出目录结构验证：确保每份数据都“活”着

下载完成后，检查输出目录是否符合预期。以知乎为例，./zhihu_archive/应包含：

zhihu_daily_123456/ ├── content.md ├── images/ │ ├── 1.jpg │ └── formula_abc.png # 知乎公式渲染图 ├── video.mp4 # 若文章含视频 └── metadata.json

验证要点：

• content.md中的图片路径是否为![](images/1.jpg)，而非绝对 URL；
• images/下的文件名是否与 Markdown 中引用的一致；
• metadata.json的published_at字段是否为 ISO 格式（如"2024-03-10T15:22:33+08:00"），不是时间戳数字；
• 打开content.md，用 Typora 预览，确认公式、代码块、引用块渲染正常。

实操心得：我最初漏了formula_abc.png的下载，知乎的 LaTeX 公式是用 Katex 渲染成 PNG 的，URL 在<img src="https://www.zhihu.com/equation?tex=...">里。后来加了正则r'https://www\.zhihu\.com/equation\?tex=[^"]+'专门抓这类图片，才解决公式丢失问题。

5. 常见问题与排查技巧实录：那些文档里不会写的坑

5.1 知乎下载报 403：不是被封，是 header 缺了字段

现象：脚本运行时报requests.exceptions.HTTPError: 403 Client Error，但浏览器能正常打开。
原因：知乎除了x-zse-96，还校验x-zse-93和cookie中的tgw_l7_route（反爬路由标识）。
解决：

• x-zse-93是时间戳（毫秒级），直接str(int(time.time() * 1000))；
• tgw_l7_route需从浏览器 Cookie 复制，脚本中用session.cookies.set('tgw_l7_route', 'xxxxxx')注入；
• 最终 header 示例：

  headers = { 'x-zse-96': zse96_value, 'x-zse-93': str(int(time.time() * 1000)), 'User-Agent': fake_ua.random, 'Cookie': 'tgw_l7_route=xxxxxx; z_c0=xxxxxx' }

注意：tgw_l7_route有效期约 24 小时，过期后手动更新一次即可，比逆向加密简单。

5.2 雪球 PDF 表格乱码：字体嵌入导致文字识别失败

现象：PyPDF2提取的 PDF 文字全是方框或乱码（如□□□□）。
原因：雪球 PDF 使用了未嵌入的中文字体（如“思源黑体”），PyPDF2无法映射字符。
解决：改用pdfplumber，它能处理字体映射：

import pdfplumber with pdfplumber.open("file.pdf") as pdf: page = pdf.pages[0] text = page.extract_text() # 自动处理字体

但pdfplumber较慢，所以我的脚本逻辑是：先用PyPDF2快速尝试，若检测到乱码（正则r'[\u4e00-\u9fff].*?□'），再 fallback 到pdfplumber。

5.3 微博视频下载卡死：M3U8 解析失败或 TS 文件 403

现象：脚本卡在Downloading seg-1.ts...，无响应。
原因：微博 M3U8 文件可能含#EXT-X-KEY加密字段，或 TS URL 需要 Referer。
解决：

• 检查 M3U8 内容，若含#EXT-X-KEY，说明加密，当前方案不支持（需解密密钥，涉及法律风险，主动放弃）；
• 若无加密，确保 TS 请求头带Referer: https://weibo.com/和Cookie；
• 加超时和重试：requests.get(url, timeout=30, headers=headers)，失败重试 3 次。

实操心得：微博对视频下载限制严格，单个视频超过 5 分钟大概率失败。我的策略是：只下载 3 分钟内的教程类视频，新闻类长视频直接跳过——聚焦核心需求，不硬刚。

5.4 元数据时间错乱：时区转换失误导致published_at偏移 8 小时

现象：metadata.json中published_at是"2024-03-10T07:22:33Z"，但原文发布时间是下午 3 点。
原因：知乎 API 返回的时间是 UTC（Z 结尾），但网页显示的是北京时间（UTC+8），脚本未转换。
解决：用dateutil库自动解析：

from dateutil import parser utc_time = parser.isoparse("2024-03-10T07:22:33Z") beijing_time = utc_time.astimezone(pytz.timezone('Asia/Shanghai')) metadata['published_at'] = beijing_time.isoformat()

这样published_at就是"2024-03-10T15:22:33+08:00"，与网页一致。

5.5 批量下载中断后如何续传：避免重复劳动

现象：下载 100 篇知乎文章，跑到第 60 篇时网络中断，重启后从头开始。
解决：脚本内置断点续传。每个平台模块在下载前，先扫描输出目录，生成已存在 ID 列表：

existing_ids = set() for folder in os.listdir(config['output_dir']): if folder.startswith('zhihu_'): existing_ids.add(folder.split('_')[1]) # 过滤掉已存在的 post_id to_download = [pid for pid in config['post_ids'] if str(pid) not in existing_ids]

这样中断后重启，只会下载剩余的 40 篇，不重复、不遗漏。

6. 进阶扩展与实用技巧：让归档系统更智能

6.1 自动去重：用 SimHash 算法识别相似内容

不同平台可能发布相同内容（如知乎专栏和雪球同步发文）。手动去重费眼，我用simhash库实现自动判重：

• 对每篇文章提取关键词（去掉停用词），生成 64 位指纹；
• 计算两两指纹的汉明距离，小于 3 判定为重复；
• 保留发布时间早的那篇，另一篇标记为duplicate_of: zhihu_123456。

代码片段：

from simhash import Simhash def get_simhash(text): words = [w for w in jieba.cut(text) if w not in stopwords] return Simhash(words).value # 比较 dist = bin(hash1 ^ hash2).count('1') if dist < 3: print("重复内容，跳过")

实测对知乎长文（2000 字以上）准确率 92%，误杀率低于 1%。

6.2 关键词高亮：用正则在 Markdown 中自动标注重点

下载完成后，想快速定位“机器学习”“现金流”等关键词？脚本可自动添加高亮：

keywords = ["机器学习", "现金流", "曝光补偿"] for kw in keywords: markdown_text = re.sub( f'({kw})', r'<mark>\1</mark>', markdown_text, flags=re.IGNORECASE )

生成的 Markdown 在支持 HTML 的编辑器（如 Typora）中会显示黄色高亮，阅读效率提升明显。

6.3 一键导入 Obsidian：生成双向链接知识图谱

如果你用 Obsidian 做知识管理，脚本可额外生成.md文件，含[[链接]]语法：

--- tags: [投资, A股] aliases: [雪球-价值捕手-2024Q1财报] --- # {{title}} 原文来自 [[雪球-价值捕手-2024Q1财报]]，发布时间 {{published_at}}。

这样所有归档内容自动成为 Obsidian 知识图谱的节点，点击就能跳转，比文件夹管理直观得多。

最后分享一个小技巧：我把整个归档系统打包成 Docker 镜像，定时任务每天凌晨 2 点自动运行docker run -v /my/archive:/app/output archive-bot，醒来就能看到新下载的内容。不用开电脑、不用管脚本，真正的“设置好就忘掉”。