基于n8n的社媒调研工作流：保留原帖证据的四个模板

1. 为什么社媒调研必须保留原帖证据

做社媒调研的人都有一个共同的痛点：数据抓下来了，报告写完了，等到要复盘或者被人质疑的时候，回头去找原始帖子，发现已经被删了、被编辑了、或者账号直接注销了。尤其是做竞品分析、舆情监测、KOL筛选这类工作，原始证据的留存直接决定了调研结论的可信度。

我最早做社媒调研的时候，用的是最笨的办法——手动截图、复制粘贴到表格里。一条两条还行，一旦量级上到几百条，整个人就废了。后来开始用自动化工具，试过不少方案，最终稳定在n8n上。原因很简单：n8n的HTTP Request节点足够灵活，能直接调各平台的API；工作流可以导出成JSON模板，团队里谁都能一键导入复用；最关键的是，它能在抓取数据的同时把原始响应完整存档，这就是“保留原帖证据”的技术基础。

这篇内容围绕四个独立的n8n工作流模板展开，分别对应四种典型的社媒调研场景。每个模板都是完整的、可以直接导入n8n运行的JSON工作流，我会把设计思路、节点配置、参数计算、踩坑经验全部拆开讲。不管你是刚接触n8n的新手，还是已经在用n8n做自动化但想优化调研流程的老手，都能从里面找到可以直接抄作业的东西。

先说一下这四个模板分别解决什么问题：

• 模板一：关键词实时监控流——针对特定关键词，定时抓取最新帖子，保留原始JSON响应和页面快照
• 模板二：竞品账号批量采集流——输入一批账号ID，批量拉取近期帖子，自动归档到本地和数据库
• 模板三：话题标签追踪流——围绕某个话题标签，持续追踪帖子增长趋势，保留每个时间切片的数据
• 模板四：单帖深度取证流——针对单条重点帖子，抓取完整互动数据、评论区和编辑历史

四个模板共享一套“证据留存”的核心逻辑，但在触发方式、数据处理和存储策略上各有侧重。下面逐个拆解。

2. 四个模板的公共底座设计

2.1 证据留存的三层结构

在讲具体模板之前，必须先说清楚“保留原帖证据”到底保留什么。我的做法是三层结构：

第一层：原始API响应。每次HTTP Request拿到的完整JSON，不做任何裁剪，原封不动存下来。这层证据的价值在于，它是平台返回的原始数据，任何后续的数据处理都不会影响它的完整性。存的时候按平台_帖子ID_时间戳.json命名，方便回溯。

第二层：结构化字段。从原始JSON里提取出帖子ID、作者、发布时间、正文、互动数据等关键字段，存到数据库或表格里。这层是给日常查询和统计分析用的，追求的是查询效率。

第三层：页面快照。对于重点帖子，额外抓一次网页HTML存档。因为API返回的数据和用户在页面上看到的可能不完全一致，比如有些平台会在页面上展示“已编辑”标记，但API里不一定有。页面快照是最后的兜底证据。

注意：三层结构不是每个模板都必须全用。模板一和模板三偏重第一层和第二层，模板二和模板四会加上第三层。根据你的调研目的选择，没必要为了“全”而增加不必要的存储成本。

2.2 n8n里的关键节点选型

四个模板共用几个核心节点，这里统一说明选型理由：

HTTP Request节点：这是整个工作流的心脏。n8n的HTTP Request节点支持GET/POST/PUT/DELETE，支持自定义Header、Query参数、Body，还能配置认证信息。我试过用Function节点直接发请求，灵活度确实更高，但调试成本也高，而且n8n的HTTP Request节点自带重试机制和错误处理，对于社媒API这种经常抽风的场景来说，稳定性更重要。

Code节点：用来做数据清洗和字段提取。n8n的Code节点支持JavaScript，可以写复杂的处理逻辑。我一般把“从原始JSON里提取结构化字段”这一步放在Code节点里做，因为不同平台的JSON结构差异很大，用Code节点比用Set节点灵活得多。

IF节点：做条件判断。比如判断API返回是否成功、判断帖子发布时间是否在目标范围内、判断互动数据是否达到阈值。IF节点是控制工作流分支的关键。

Merge节点：把多个分支的数据合并。比如模板二里批量采集多个账号的数据，每个账号的请求结果需要合并成一个数组再统一处理。

Write Binary File节点：把原始JSON和页面快照写到本地磁盘。这个节点支持自定义文件路径和文件名，可以用表达式动态生成文件名。

Postgres节点：把结构化字段写入数据库。n8n原生支持Postgres、MySQL、MongoDB等主流数据库。我选Postgres是因为它的JSONB字段类型特别适合存半结构化的社媒数据。

2.3 认证与限流处理

社媒平台的API基本都需要认证。n8n的Credentials系统支持OAuth2、API Key、Header Auth等多种方式。我的建议是：能用OAuth2就用OAuth2，能用API Key就用API Key，尽量不要把token硬编码在HTTP Request节点里。原因很简单，硬编码的token一旦泄露，换起来很麻烦；而Credentials是加密存储的，而且可以在多个工作流之间复用。

限流是另一个必须处理的问题。大部分社媒API都有速率限制，比如每分钟最多60次请求。我的做法是在工作流里加一个Wait节点，每次请求之间间隔1-2秒。对于批量采集的场景，还会加一个计数器，每请求N次就多等一会儿。具体参数要根据目标平台的限流策略来定，后面每个模板里会详细说。

3. 模板一：关键词实时监控流

3.1 适用场景与触发设计

这个模板解决的是“我想持续监控某个关键词，一有新帖子就抓下来”的需求。典型场景包括：品牌舆情监控、行业热点追踪、竞品动态监测。

触发方式我选的是Schedule Trigger，也就是定时触发。为什么不选Webhook？因为大部分社媒平台不提供Webhook推送，你只能主动去拉。定时间隔根据关键词的热度来定：热点关键词建议5-10分钟一次，普通关键词30分钟到1小时一次就够了。我一般设15分钟，兼顾时效性和API配额。

Schedule Trigger的配置很简单，在n8n里选“Schedule Trigger”节点，设置Interval为Minutes，Value为15。如果你想更精细地控制，比如只在工作时间段运行，可以用Cron表达式，比如*/15 9-18 * * 1-5表示周一到周五的9点到18点之间每15分钟触发一次。

3.2 HTTP Request节点的参数配置

这是整个模板最核心的部分。以某平台的搜索API为例，请求配置如下：

{ "method": "GET", "url": "https://api.example.com/search", "authentication": "genericCredentialType", "genericAuthType": "httpHeaderAuth", "sendQuery": true, "queryParameters": { "parameters": [ { "name": "q", "value": "{{ $json.keyword }}" }, { "name": "count", "value": "50" }, { "name": "sort", "value": "recency" } ] }, "options": { "timeout": 30000, "retry": { "retry": { "enabled": true, "maxRetries": 3, "waitBetweenRetries": 5000 } } } }

几个关键点解释一下：

count参数：大部分平台单次请求最多返回50-100条。我设50是因为再多了响应体太大，处理起来慢，而且容易触发限流。如果你需要更多数据，用分页参数翻页。

sort参数：设成recency（按时间倒序）是为了配合定时触发。每次只抓最新的，然后用帖子ID去重，这样就不会重复处理老数据。

timeout：设30秒。社媒API偶尔会抽风，响应特别慢，设太短容易误判为失败，设太长会卡住整个工作流。

retry：开启重试，最多3次，每次间隔5秒。这个配置能解决大部分偶发的网络抖动和临时限流。

实操心得：如果你的目标平台API不支持按时间排序，那就只能全量拉取然后在Code节点里过滤。这种情况下建议把count设小一点，比如20，然后增加请求频率，用时间换空间。

3.3 证据留存的具体实现

HTTP Request拿到响应后，先过一个IF节点判断状态码。如果状态码不是200，走错误处理分支，记录错误日志并发送通知。如果是200，进入证据留存流程。

证据留存分两步走：

第一步：原始响应存档。用Write Binary File节点，把完整的响应体写到本地。文件路径用表达式动态生成：

/data/social_media_evidence/{{ $json.platform }}/{{ $json.keyword }}/{{ $now.format('yyyy-MM-dd') }}/{{ $json.post_id }}_{{ $now.format('yyyyMMddHHmmss') }}.json

这个路径结构的好处是按平台、关键词、日期三级分类，找起来方便。文件名里带帖子ID和时间戳，保证唯一性。

第二步：结构化字段提取。用Code节点写JavaScript，从原始JSON里提取关键字段：

const items = $input.all(); const results = []; for (const item of items) { const raw = item.json; const posts = raw.data?.posts || raw.results || []; for (const post of posts) { results.push({ json: { post_id: post.id, author_id: post.author?.id, author_name: post.author?.name, content: post.text || post.content, published_at: post.created_at, like_count: post.metrics?.likes || 0, comment_count: post.metrics?.comments || 0, share_count: post.metrics?.shares || 0, raw_response: JSON.stringify(post), collected_at: new Date().toISOString() } }); } } return results;

这段代码的关键在于raw_response字段，它把每条帖子的原始JSON也存了一份。这样即使后续字段提取逻辑有变化，原始数据还在。

3.4 去重与增量处理

定时抓取最大的问题是重复数据。我的去重策略是：用帖子ID做唯一键，在写入数据库时做UPSERT。Postgres的ON CONFLICT DO NOTHING或者ON CONFLICT DO UPDATE都能实现。

具体做法是在Postgres节点里配置：

INSERT INTO social_media_posts (post_id, author_id, content, published_at, like_count, comment_count, share_count, raw_response, collected_at) VALUES ($1, $2, $3, $4, $5, $6, $7, $8, $9) ON CONFLICT (post_id) DO UPDATE SET like_count = EXCLUDED.like_count, comment_count = EXCLUDED.comment_count, share_count = EXCLUDED.share_count, collected_at = EXCLUDED.collected_at;

这样设计的好处是：新帖子插入，老帖子更新互动数据。互动数据是随时间变化的，每次抓取都更新一下，能追踪帖子的热度变化趋势。

注意：ON CONFLICT DO UPDATE会覆盖老数据，如果你需要保留每次抓取的历史互动数据，就不要用UPDATE，而是单独建一张post_metrics_history表，每次抓取都INSERT一条新记录。

4. 模板二：竞品账号批量采集流

4.1 批量输入的两种方式

这个模板解决的是“我有一批竞品账号，想批量拉取它们近期的帖子”的需求。输入方式有两种：

方式一：手动输入账号列表。在n8n里用一个Set节点，把账号ID写成数组：

{ "accounts": [ {"platform": "twitter", "account_id": "competitor_a"}, {"platform": "twitter", "account_id": "competitor_b"}, {"platform": "linkedin", "account_id": "competitor_c"} ] }

方式二：从数据库读取账号列表。用Postgres节点查一张competitor_accounts表，把结果作为输入。这种方式适合账号数量多、经常变动的场景。

我一般用方式二，因为账号列表维护在数据库里，增删改都方便，不用每次改工作流。

4.2 Split In Batches节点的使用

拿到账号列表后，不能一次性全部请求，那样会瞬间触发限流。要用Split In Batches节点把数组拆开，每次处理一个账号。

Split In Batches节点的配置：Batch Size设为1，表示每次处理一个账号。节点会输出两个分支：一个输出当前批次的账号数据，一个输出“还有剩余”的信号。把“还有剩余”的信号连回Split In Batches节点，形成循环，直到所有账号处理完。

这个节点的妙处在于，它自动处理了循环逻辑，你不需要写任何循环代码。而且可以在循环里加Wait节点，控制请求频率。

4.3 分页拉取的实现

大部分平台的账号帖子API都支持分页。以某平台为例，请求参数里有max_id和since_id两个参数，分别用于向前和向后翻页。

我的做法是：只拉取最近N天的帖子，不拉全量。因为竞品分析通常关注近期动态，拉全量既慢又浪费配额。具体实现是在HTTP Request节点里加一个since_date参数，设成当前日期减去N天。

如果平台不支持按日期过滤，那就只能翻页。翻页的逻辑是：在Code节点里判断响应里有没有next_cursor字段，如果有，就把cursor存到一个变量里，下一轮请求带上这个cursor。这个逻辑用n8n的Loop Over Items节点实现比较方便。

// Code节点：判断是否需要继续翻页 const response = $input.first().json; const hasMore = response.next_cursor !== null && response.next_cursor !== undefined; return [{ json: { has_more: hasMore, next_cursor: response.next_cursor || null, posts: response.data || [] } }];

然后用IF节点判断has_more，如果为true，走继续翻页的分支；如果为false，走结束分支。

4.4 页面快照的抓取

竞品账号的帖子，我建议额外抓一次页面快照。因为API返回的数据可能不包含页面上的所有信息，比如置顶标记、编辑标记、引用帖子的完整内容等。

抓页面快照用HTTP Request节点请求帖子的网页URL，然后把响应的HTML存成文件。这里有个坑：很多平台的网页是JavaScript渲染的，直接请求HTML拿到的可能是空壳。解决办法有两个：一是用平台提供的oEmbed接口，能拿到部分渲染后的内容；二是用无头浏览器，但n8n本身不内置无头浏览器，需要额外部署服务。

我的选择是：能用oEmbed就用oEmbed，不能用就只存API数据。因为无头浏览器的维护成本太高，对于大部分调研场景来说，API数据已经够用了。

实操心得：如果你确实需要页面快照，可以考虑在n8n之外单独跑一个Playwright服务，然后n8n通过HTTP Request调用这个服务。这样架构更清晰，n8n只负责编排，渲染交给专业工具。

4.5 存储策略与数据归档

批量采集的数据量比较大，存储策略要提前规划。我的方案是：

• 原始JSON：存本地磁盘，按平台/账号ID/日期三级目录归档。保留周期6个月，过期自动清理。
• 结构化字段：存Postgres，保留周期1年。超过1年的数据归档到冷存储。
• 页面快照：只对重点帖子抓取，存本地磁盘，保留周期1年。

清理逻辑用一个单独的Schedule Trigger工作流实现，每天凌晨跑一次，删除过期文件。这样主采集工作流不用管清理的事，职责分离。

5. 模板三：话题标签追踪流

5.1 话题追踪与关键词监控的区别

话题标签追踪和关键词监控看起来很像，但有一个本质区别：话题标签的数据是持续增长的，你需要追踪的是增长趋势，而不是单条帖子。

举个例子，你监控“#某品牌新品”这个话题，你不仅想知道有哪些帖子，还想知道这个话题的热度是在上升还是下降，哪个时间点出现了爆发，哪些账号在推动话题发酵。这就要求工作流不仅要抓帖子，还要记录每个时间切片的汇总数据。

5.2 时间切片数据的采集

我的做法是：每次抓取时，除了存帖子数据，还额外计算一组汇总指标，存到单独的表里。

汇总指标包括：

这些指标用Code节点计算，然后存到hashtag_metrics表里。表结构大概是：

CREATE TABLE hashtag_metrics ( id SERIAL PRIMARY KEY, hashtag VARCHAR(255) NOT NULL, platform VARCHAR(50) NOT NULL, time_slice TIMESTAMP NOT NULL, post_count INTEGER, total_engagement BIGINT, unique_authors INTEGER, top_post_id VARCHAR(255), avg_sentiment DECIMAL(3,2), created_at TIMESTAMP DEFAULT NOW() );

有了这张表，你就可以用SQL查话题的增长趋势了。比如查最近7天每小时的热度变化：

SELECT date_trunc('hour', time_slice) AS hour, SUM(post_count) AS total_posts, SUM(total_engagement) AS total_engagement FROM hashtag_metrics WHERE hashtag = '#某品牌新品' AND time_slice >= NOW() - INTERVAL '7 days' GROUP BY hour ORDER BY hour;

5.3 情感分析的集成

情感分析不是n8n原生支持的功能，需要调外部API。我试过几个方案：

方案一：调大模型API。把帖子正文发给大模型，让它返回情感得分。优点是准确率高，能理解反讽、隐喻等复杂表达；缺点是成本高，每条帖子都要调一次API。

方案二：用开源情感分析库。在n8n的Code节点里引入sentiment这个npm包，做本地分析。优点是免费、快；缺点是准确率一般，对中文支持不太好。

方案三：关键词匹配。自己维护一个正面词库和负面词库，做简单的词频统计。优点是极快、零成本；缺点是准确率最低，只能做粗略判断。

我的选择是：日常监控用方案三，重点话题用方案一。日常监控不需要太精确，粗略判断就够了；重点话题值得花成本调大模型API。

调大模型API的Code节点示例：

const posts = $input.all(); const results = []; for (const post of posts) { const content = post.json.content; // 调用情感分析API const response = await $http.request({ method: 'POST', url: 'https://api.example.com/sentiment', body: { text: content, model: 'sentiment-v1' }, headers: { 'Authorization': 'Bearer ' + $credentials.sentimentApiKey } }); results.push({ json: { ...post.json, sentiment_score: response.data.score, sentiment_label: response.data.label } }); } return results;

注意：在Code节点里发HTTP请求会阻塞工作流，如果帖子数量多，整个流程会很慢。建议把情感分析拆成独立的工作流，用队列的方式异步处理。

5.4 话题爆发检测

话题追踪最有价值的功能是爆发检测——在话题热度突然上升时及时通知你。

实现逻辑是：每次采集完汇总指标后，跟过去N个时间切片的平均值做对比。如果当前值超过平均值的M倍，就触发告警。

// Code节点：爆发检测 const current = $input.first().json; const history = $input.all().slice(1); // 历史数据 const avgPostCount = history.reduce((sum, item) => sum + item.json.post_count, 0) / history.length; const threshold = avgPostCount * 3; // 超过平均值3倍视为爆发 if (current.post_count > threshold) { return [{ json: { alert: true, hashtag: current.hashtag, current_count: current.post_count, avg_count: avgPostCount, message: `话题 ${current.hashtag} 出现爆发，当前帖子数 ${current.post_count}，历史平均 ${avgPostCount.toFixed(0)}` } }]; } return [{ json: { alert: false } }];

告警渠道可以用n8n的Email节点、Slack节点、或者Webhook节点推送到你自己的告警系统。

6. 模板四：单帖深度取证流

6.1 什么情况下需要单帖取证

前面三个模板都是批量处理，模板四是针对单条帖子的深度取证。典型场景包括：

• 某条帖子突然爆火，需要完整记录它的所有数据
• 某条帖子涉及侵权或违规，需要固定证据
• 某条帖子是竞品的核心营销内容，需要深度分析

单帖取证的特点是：数据要全、要深、要能经得起质疑。所以这个模板会抓取比前面三个模板更多的数据维度。

6.2 完整数据维度的抓取

单帖取证要抓的数据包括：

帖子基础数据：帖子ID、作者信息、发布时间、正文、编辑历史、置顶状态。

互动数据：点赞数、评论数、转发数、收藏数、浏览量。这些数据要抓多次，记录变化趋势。

评论区数据：评论内容、评论作者、评论时间、评论点赞数。评论区往往能反映真实的用户反馈。

传播路径数据：哪些账号转发了这条帖子、转发时间、转发时的评论。传播路径能看出话题的扩散模式。

页面快照：完整的HTML存档，包括页面上的所有可见元素。

抓取这些数据需要调多个API接口，用n8n的并行分支来实现。具体做法是：一个Trigger节点触发后，分出多个HTTP Request节点并行请求不同的接口，然后用Merge节点合并结果。

6.3 编辑历史的追踪

编辑历史是单帖取证里最容易被忽略但最重要的数据。很多平台允许作者编辑已发布的帖子，编辑后的内容可能跟原始内容完全不同。如果你只抓了编辑后的版本，就丢失了原始证据。

追踪编辑历史的方法因平台而异：

方法一：API直接返回编辑历史。有些平台的API会返回edit_history字段，包含每次编辑的时间和内容。这种情况最简单，直接存下来就行。

方法二：定期抓取对比。如果API不返回编辑历史，就只能定期抓取帖子内容，然后对比前后差异。这个方法的局限是，如果两次抓取之间发生了多次编辑，你只能看到最终结果，看不到中间过程。

方法三：页面快照对比。每次抓取时存一份页面快照，然后对比不同时间点的快照。这个方法能捕捉到API可能遗漏的编辑标记。

我的做法是：方法一优先，方法二兜底，方法三补充。具体用哪个，取决于目标平台的支持情况。

6.4 证据链的完整性保障

单帖取证的最终目的是形成完整的证据链。什么叫完整？就是任何人拿到你的证据包，都能清楚地看到：这条帖子在什么时间、什么平台、由谁发布、内容是什么、有多少互动、评论区说了什么、有没有被编辑过。

为了达到这个标准，我设计了一个证据包的结构：

evidence_package/ ├── metadata.json # 证据包元信息：采集时间、采集人、采集工具版本 ├── post_raw.json # 帖子原始API响应 ├── post_structured.json # 帖子结构化字段 ├── comments_raw.json # 评论区原始API响应 ├── comments_structured.json # 评论区结构化字段 ├── metrics_history.json # 互动数据变化历史 ├── edit_history.json # 编辑历史 ├── page_snapshot.html # 页面快照 └── checksum.txt # 所有文件的SHA256校验和

checksum.txt是关键，它记录了每个文件的哈希值，用来验证文件有没有被篡改。生成校验和的Code节点：

const crypto = require('crypto'); const fs = require('fs'); const files = [ 'metadata.json', 'post_raw.json', 'post_structured.json', 'comments_raw.json', 'comments_structured.json', 'metrics_history.json', 'edit_history.json', 'page_snapshot.html' ]; const checksums = []; for (const file of files) { const content = fs.readFileSync(`/data/evidence_package/${file}`); const hash = crypto.createHash('sha256').update(content).digest('hex'); checksums.push(`${hash} ${file}`); } fs.writeFileSync('/data/evidence_package/checksum.txt', checksums.join('\n')); return [{ json: { status: 'checksum_generated', file_count: files.length } }];

实操心得：证据包的存储路径建议用/data/evidence_package/{平台}_{帖子ID}_{采集日期}/这样的格式，一眼就能看出是哪条帖子、什么时候采集的。另外，证据包生成后建议立即备份到另一个存储位置，防止单点故障。

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

7.1 API认证失败的排查

问题现象：HTTP Request节点返回401 Unauthorized，错误信息类似incorrect api key provided: sk-svcac****。

排查步骤：

1. 检查Credentials配置。在n8n的Credentials页面找到对应的认证信息，确认API Key没有过期、没有拼写错误。
2. 检查Header名称。不同平台的认证Header名称不一样，有的是Authorization，有的是X-API-Key，有的是Bearer。确认你用的Header名称跟平台文档一致。
3. 检查请求URL。有些平台的认证信息是跟URL绑定的，换了一个API端点可能就需要不同的认证。
4. 检查IP白名单。部分平台要求API调用来源IP在白名单里，如果你的n8n部署在动态IP的环境里，可能会被拒绝。

常见坑：n8n的Credentials系统里，如果你选了Generic Credential Type，然后选Header Auth，Header的名称和值要分别填。我见过有人把Bearer sk-xxx整个填到值里，结果Header变成了Authorization: Bearer sk-xxx，多了一个Bearer，导致认证失败。正确的做法是：Header名称填Authorization，值填Bearer sk-xxx。

7.2 请求超时与重试策略

问题现象：HTTP Request节点报ETIMEDOUT或ECONNRESET。

排查步骤：

1. 检查目标API的响应时间。用curl或Postman单独请求一次，看响应时间是多少。如果超过30秒，说明是API本身慢，需要调大timeout。
2. 检查网络连接。如果你的n8n部署在本地，而目标API在海外，网络延迟可能很高。这种情况建议把n8n部署在离API服务器更近的区域。
3. 检查请求频率。如果短时间内发了大量请求，可能被平台限流，表现为连接被重置。降低请求频率，加Wait节点。

重试策略配置：

{ "retry": { "enabled": true, "maxRetries": 3, "waitBetweenRetries": 5000 } }

这个配置的意思是：失败后重试3次，每次间隔5秒。对于大部分偶发故障，这个配置够用了。如果还是失败，说明是持续性故障，需要人工介入。

7.3 数据去重与增量更新

问题现象：数据库里出现重复帖子，或者互动数据没有更新。

排查步骤：

1. 检查去重键。确认你用的去重键（通常是帖子ID）在平台上是唯一的。有些平台的帖子ID在不同接口里格式不一样，比如一个是数字，一个是字符串，这会导致去重失败。
2. 检查UPSERT语句。确认ON CONFLICT子句里的字段名跟表结构的唯一约束一致。
3. 检查时间戳。如果你用时间戳做增量更新的依据，确认时间戳的时区设置正确。我踩过这个坑：n8n默认用UTC时间，但平台API返回的是本地时间，导致增量更新漏掉了一些帖子。

解决方案：统一用UTC时间。在Code节点里把所有时间戳都转成UTC：

const publishedAt = new Date(post.created_at); const publishedAtUtc = publishedAt.toISOString();

7.4 存储空间不足的处理

问题现象：Write Binary File节点报ENOSPC: no space left on device。

排查步骤：

1. 检查磁盘使用情况。用df -h命令看哪个分区满了。
2. 检查证据文件的保留策略。如果保留周期设得太长，或者没有自动清理机制，磁盘很快就会被占满。
3. 检查是否有大文件。页面快照的HTML文件可能很大，尤其是包含大量图片的页面。

解决方案：

• 设置自动清理工作流，每天删除过期文件。
• 对页面快照做压缩，用gzip格式存储。
• 把证据文件存到对象存储（如S3、OSS），而不是本地磁盘。n8n有S3节点，可以直接上传。

7.5 常见问题速查表

8. 四个模板的选型建议与组合使用

8.1 按调研目的选模板

四个模板不是互斥的，可以组合使用。选型建议如下：

• 只想监控关键词热度：模板一就够了。
• 要做竞品账号分析：模板二 + 模板三。模板二拉帖子，模板三做趋势分析。
• 要做深度内容分析：模板四 + 模板一。模板一发现热点，模板四深度取证。
• 要做完整的舆情监测系统：四个模板全上，用同一个数据库，数据互通。

8.2 性能与成本的平衡

四个模板全跑起来，API调用量和存储成本都不低。我的经验是：

• API配额：优先保证模板一和模板三，因为这两个是持续运行的。模板二和模板四按需触发，不占日常配额。
• 存储成本：原始JSON和页面快照占空间最大。如果预算有限，可以只对重点帖子存页面快照，普通帖子只存原始JSON。
• 计算成本：情感分析最贵。日常监控用关键词匹配，重点话题才调大模型API。

8.3 后续扩展方向

这套工作流跑稳定之后，可以往几个方向扩展：

方向一：接入BI工具。把Postgres里的数据接到Metabase或Superset，做可视化看板。这样不用写SQL就能看趋势。

方向二：自动生成调研报告。用n8n的Code节点调大模型API，把结构化数据转成自然语言报告，定时发到邮箱。

方向三：多平台统一。目前四个模板主要针对单一平台，可以扩展成多平台适配器，用Switch节点根据平台类型走不同的处理逻辑。

方向四：实时告警。把爆发检测的结果推到Slack或钉钉，实现实时告警。

我个人在实际操作中的体会是：先把一个模板跑通，再逐步加其他模板。不要一上来就四个全上，那样出了问题很难定位。我最早就是四个一起上，结果API限流、数据库锁、磁盘满三个问题同时爆发，排查了一整天才搞定。后来改成逐个上线，每个模板跑一周稳定后再加下一个，顺利多了。

最后分享一个小技巧：n8n的工作流可以导出成JSON文件，建议每次修改后都导出一份存档，命名带上日期和版本号。这样万一改坏了，可以快速回滚到上一个稳定版本。我一般用workflow_name_v1.2_20250115.json这样的命名格式，清晰明了。