在一次竞品监控任务中，抓取接口的平均响应时间只有 420 毫秒，数据库批量写入也没有明显变慢，但一批 18 万条商品记录仍然从 11 分钟拖到了 47 分钟。最初团队把问题归因于平台限流和数据库索引，后来通过阶段埋点才发现：真正占用时间的不是请求，也不是写入，而是清洗流程中一个针对长文本的重复扫描逻辑。电商数据抓取系统变慢时，先不要急着换爬虫框架或加机器，第一步应该是证明“慢发生在哪个阶段、哪类数据、哪段代码”。

本文复盘的重点，不是如何获取竞品数据，也不是如何制作竞品分析报告，而是竞品监控数据已经抓回来之后，开发人员如何定位清洗阶段的耗时来源。我会按照实际排查顺序，拆解阶段耗时、异常样本、数据格式漂移、代码热点、去重策略和优化验证，并给出不同数据规模和业务时效要求下的取舍方案。

一、先讲核心结论：清洗变慢通常不是一个“函数慢”这么简单

1. 先定位阶段，再定位函数，最后定位数据

竞品监控任务通常包含请求、解析、字段提取、清洗、去重、写入和指标计算等环节。总耗时上升，只能说明任务变慢，不能说明是网络、解析、清洗还是数据库造成的。

我排查这类问题时，通常遵循三个层次。第一层看阶段，确认清洗在总耗时中的占比；第二层看函数，确认是正则、日期解析、去重还是字段映射消耗时间；第三层看数据，确认是所有商品都变慢，还是少数长文本、异常页面或复杂变体拖慢了批次。

如果没有这三个层次的证据，所谓“优化清洗”很容易变成凭感觉改代码。常见结果是网络线程增加了，任务仍然超时；数据库索引重建了，清洗阶段仍然占据大头；甚至换了语言或框架，问题只是在不同位置重新出现。

2. 清洗耗时要同时看平均值和长尾

平均单条耗时很容易制造错觉。假设 10 万条商品数据平均每条清洗 2 毫秒，总耗时看起来应该只有 200 秒，但如果其中 1% 的记录包含超长 HTML、嵌套规格或异常评价字段，批处理中的长尾就可能让整体任务被少数记录拖住。

因此，清洗阶段至少要保留平均耗时、P95、P99、最大耗时和异常记录数。平均值适合观察整体趋势，P95 适合判断大多数任务是否稳定，P99 和最大耗时则用于定位是否存在极端样本。

3. 性能优化不能脱离数据质量

电商数据清洗不是纯粹的性能计算。金额、销量、评价数、促销标签、规格变体和库存状态都可能因为页面结构变化而产生格式漂移。某个正则表达式被简化后，任务可能快了 30%，但价格区间被错误解析成单个价格，最终会影响竞品价格带和告警结果。

我更倾向于把优化目标定义为：在可接受的数据差异范围内，降低稳定批次耗时和长尾耗时，同时保留异常样本的可追溯性。只看速度，不看字段正确率，不能算完整优化。

二、真实场景：抓取成功了，为什么监控任务还是越来越慢

1. 竞品监控链路中的清洗位置

一个常见的竞品监控链路大致如下：定时任务读取商品清单，向目标页面或接口发起请求，保存原始响应，提取标题、价格、销量、评价、库存、规格和促销字段，再进行格式统一、异常修正、去重和入库。

真正容易失控的地方往往不在请求阶段，而在“原始数据到标准字段”的转换过程中。页面字段看起来不多，但一个商品可能包含多个变体、多段富文本、几十条规格属性和不同时间点的历史快照。数据规模不大时，这些操作没有明显问题；一旦监控对象扩大，隐藏的重复计算就会被放大。

我遇到过一个典型情况：业务方把监控商品数从 2.4 万增加到 8.6 万，抓取请求数量增加了约 3.6 倍，但任务耗时增加了 7 倍。表面看像是数据量增长导致的线性变慢，实际上清洗耗时占比从 36% 上升到 71%，说明流程中存在超出线性增长的处理成本。

2. 这类问题为什么容易被误判为网络问题

竞品数据抓取通常伴随重试、代理、限流和页面加载失败。任务超时时，开发人员很自然地先看请求日志。如果看到重试次数增加，就会认为网络是主要原因。

但请求重试和清洗耗时可能同时出现。比如页面结构变化后，某些响应没有按预期返回商品数据，程序把错误页面当成正文继续清洗。这样既增加了请求重试，也让清洗逻辑在超长错误文本上执行复杂正则。此时只调整请求并发数，反而可能让异常数据更快进入清洗队列。

3. 这类问题为什么也容易被误判为数据库问题

批处理任务的最后一步通常是写数据库。数据库写入耗时明显时，索引、事务、批量大小和连接池确实需要排查。但如果写入阶段只占总耗时的 8% 到 12%，继续调整数据库参数就属于优先级错误。

我建议先把“数据准备完成”和“数据库写入结束”分别打点。如果从清洗输出到写入开始之间已经等待很久，数据库可能是瓶颈；如果清洗函数迟迟没有输出完整批次，数据库只是被动等待，并不是根因。

4. 先固定一次可复现的样本

定位性能问题最怕每次测试使用不同数据。竞品页面会变化，商品库存会变化，促销标签也会变化，如果每次都重新抓取，最后无法判断耗时变化来自代码还是输入数据。

比较稳妥的做法是保存一批脱敏后的原始响应，固定记录数量、字段结构和执行环境，然后让不同版本的清洗代码在同一批输入上运行。这样才能把网络波动和业务数据变化排除在外。

三、常见误区：很多“优化动作”为什么没有解决清洗瓶颈

1. 误区一：看到任务变慢就提高并发数

提高并发数适合解决网络等待，但不适合解决单条数据清洗消耗 CPU 的问题。如果清洗是串行执行的，网络请求速度提升后，只会让更多数据更快堆积到清洗队列。

在一次排查中，请求并发从 20 提升到 60 后，下载阶段从 9 分钟降到 4 分钟，但清洗阶段从 26 分钟升到 31 分钟，进程 CPU 长时间接近 100%。最终总耗时只减少了几分钟，内存峰值却增加了一倍。

2. 误区二：看到正则表达式就全部替换

正则确实可能造成高耗时，尤其是复杂回溯规则应用于长文本时。但并不是所有正则都值得重写。针对固定前缀、简单分隔符和少量字符替换，普通字符串操作通常更容易读懂，也可能更快；而处理结构不稳定的字段时，过度简化正则会增加数据错误。

正确做法是先通过采样和基准测试确认哪一条规则耗时高，再判断是否需要缩短输入、拆分规则、预编译或替换算法。不要因为“正则看起来复杂”就把所有规则一次性推翻。

3. 误区三：把所有字段都清洗到最干净

竞品监控并不一定需要在首个同步任务中完成所有字段的深度标准化。标题、价格和库存可能需要分钟级更新，但商品详情富文本、规格说明和评价摘要可能只需要小时级或日级更新。

如果把所有字段按照最高精度、最高频率处理，系统会承担不必要的成本。更好的做法是根据业务用途拆分字段优先级：影响价格告警的字段进入实时链路，影响内容分析的字段进入低频链路，原始字段则保留在原始层供后续回溯。

4. 误区四：只看整体平均耗时

平均耗时无法回答“谁拖慢了批次”。一批 10 万条数据平均每条 5 毫秒，看起来很稳定，但如果最慢的 500 条每条耗时 2 秒，任务结束时间仍然会被这些记录决定。

建议将单条处理耗时分桶，例如 0 到 5 毫秒、5 到 20 毫秒、20 到 100 毫秒、100 到 500 毫秒和超过 500 毫秒。再把慢记录与字段长度、页面类型、错误码和商品类目关联起来，通常比单纯看平均值有用。

5. 误区五：为了快而直接丢弃异常数据

过滤异常数据可以让任务变快，但如果没有记录异常原因，业务方看到的报表可能只是“看起来正常”。例如某个平台返回验证码页面，程序将其识别为无效记录并跳过，系统耗时下降了，实际监控覆盖率却已经下降。

异常记录不一定要进入主数据表，但至少要进入异常队列，保留商品标识、请求时间、响应摘要、规则命中项和重试次数。清洗速度的提升不能以丢失监控可见性为代价。

6. 误区六：没有先固定数据就直接压测

同一段清洗代码在短标题和超长详情页上的表现可能完全不同。没有固定样本的压测，往往得到“这次很快、下次很慢”的结论，最终只能依靠主观判断。

至少应该准备正常样本、长文本样本、格式漂移样本、空字段样本、重复样本和错误页面样本。每类样本都要标记来源和数量，才能判断优化是否只对某一种数据有效。

四、专业判断逻辑：从总耗时拆到最慢记录

1. 第一步：建立阶段耗时边界

我通常会先为每个批次记录以下字段：任务编号、批次编号、输入记录数、请求次数、重试次数、解析耗时、清洗耗时、去重耗时、写入耗时、异常记录数和内存峰值。

这些字段不需要一开始就做得很复杂，关键是要能够回答三个问题：数据什么时候进入清洗，什么时候完成清洗，清洗过程中处理了多少数据。如果只能看到任务开始和结束时间，后续所有判断都缺乏证据。

task_id = "monitor_20260913_001"
metrics = {

"input_count": len(raw_items),

"request_count": request_count,

"retry_count": retry_count,

}

t0 = monotonic()

parsed_items = parse_response(raw_items)

metrics["parse_ms"] = (monotonic() - t0) * 1000

t1 = monotonic()

cleaned_items = clean_items(parsed_items)

metrics["clean_ms"] = (monotonic() - t1) * 1000

t2 = monotonic()

deduped_items = deduplicate(cleaned_items)

metrics["deduplicate_ms"] = (monotonic() - t2) * 1000

t3 = monotonic()

write_batch(deduped_items)

metrics["write_ms"] = (monotonic() - t3) * 1000

metrics["output_count"] = len(deduped_items)

metrics["error_count"] = count_errors(cleaned_items)

logger.info("monitor_metrics", extra=metrics)

阶段埋点的价值不在于代码本身，而在于把猜测变成可比较的时间序列。连续观察几批任务后，才能判断清洗耗时是随数据量线性增长，还是因为某个字段变化出现突增。

2. 第二步：判断是总量问题还是长尾问题

如果每条记录耗时相对稳定，任务耗时大致会随着记录数线性增长。这种情况下，优化重点通常是减少处理范围、增量处理或提高并行度。

如果平均耗时变化不大，但 P99 和最大耗时明显上升，重点就不应放在整体并发，而应放在异常记录。需要把最慢记录的商品编号、页面类型、字段长度、嵌套层级和异常信息打出来。

一个实用判断方法是计算“慢记录贡献率”：耗时最高的 1% 记录占总清洗耗时的比例。如果 1% 的记录贡献了 35% 以上的清洗耗时，说明长尾问题值得优先处理；如果贡献率很低，才更可能是全量逻辑本身效率不足。

3. 第三步：建立字段级耗时画像

商品记录不是一个均匀对象。标题可能只需要几十微秒，详情页清理可能需要数十毫秒，变体数组展开可能需要更多时间。因此，函数级耗时还不够，最好继续拆到字段或处理规则。

字段级画像至少要包含字段名称、输入长度、是否为空、是否包含 HTML、是否经过正则、是否产生异常和处理耗时。通过这些字段，可以识别“字段长度增长”和“规则耗时增长”之间的关系。

4. 第四步：区分“格式变化”与“代码退化”

清洗变慢不一定是代码最近变差，也可能是输入数据最近变复杂。比如目标页面增加了富文本模块，商品详情平均长度从 2,000 字符变成 8,000 字符；或者平台开始返回更多规格变体，单条记录的数组元素从 6 个增加到 32 个。

我会将近期样本与历史样本做分布对比，重点看字段长度、数组元素数、空值率、异常率和重复率。若输入分布明显变化，优化方案应包含数据边界控制，而不能只改执行逻辑。

五、具体案例：一次竞品监控清洗耗时从47分钟降回14分钟

1. 业务背景与异常表现

以下案例采用脱敏后的项目数据。任务每天采集多个电商类目的竞品商品信息，监控价格、库存、评价数量、促销状态和规格变化。优化前，每批约 18 万条商品记录，任务平均耗时 47 分钟，偶发超过 60 分钟，已经影响上午的竞品价格告警。

团队最初观察到两个现象。第一，请求平均响应时间约 420 毫秒，没有明显增加；第二，数据库批量写入平均每批 1.6 分钟，与前一周差异不大。真正异常的是清洗进程 CPU 长时间保持在 90% 以上，P99 单条处理耗时从 86 毫秒上升到 640 毫秒。

为了排除环境变量，我们保存了同一批 18 万条原始响应，在同一台机器、同一运行参数下分别运行旧版本和排查版本。这样得到的对比结果比直接在线压测更可靠。

2. 第一次拆分：清洗占据总耗时的七成

这一步排除了两个最容易被误判的方向：网络和数据库。虽然请求阶段仍有优化空间，但即使把请求耗时全部缩短，也无法解释 32.8 分钟的字段清洗耗时。

3. 第二次拆分：最慢的1%记录贡献了41%的清洗时间

我们随后输出了每条记录的清洗耗时，并按耗时从高到低排序。结果显示，最慢的 1% 记录只有 1,800 条，却贡献了整个清洗阶段约 41% 的时间。

这 1,800 条记录并不随机。它们主要来自三个类目，详情字段平均长度超过 9,000 字符，其中约 14% 的页面包含脚本片段或嵌套样式；另外一部分记录的评价摘要包含多页拼接文本，长度超过普通样本的 20 倍。

这说明问题不是“所有清洗代码都慢”，而是异常复杂数据触发了高成本路径。继续增加普通样本的并发度，不会解决这 1,800 条记录的问题。

4. 第三次拆分：发现同一文本被重复扫描四次

清洗代码原本将详情文本依次交给四个函数处理：去脚本、去样式、剥离 HTML 标签和合并空白。每个函数都会重新遍历完整字符串，并且前三个函数都使用了正则表达式。

对短文本来说，这种写法并不一定是问题，因为代码清晰、维护简单。但当输入文本达到数万字符时，四次完整扫描叠加复杂规则，长尾耗时会快速放大。

我们没有直接把四条规则合并成一个巨大正则，因为那样会增加回溯风险，也会让异常排查更困难。最终采取了分层处理：入口先识别页面类型，对明显的错误页面和超过长度阈值的内容进入异常队列；正常富文本使用一次结构化清理，再进行一次轻量空白标准化。

5. 第四次拆分：去重发生在高成本清洗之后

任务每天会重复抓取一部分商品，但旧流程要求所有记录先完整清洗，再根据商品编号和页面时间去重。当天重复率约为 23%，意味着有近四分之一的记录先支付了高昂的清洗成本，随后才被判定为无需写入。

我们将去重拆成两层。第一层使用请求阶段已知的商品标识和采集时间做轻量判断，筛掉明确重复的原始记录；第二层在必要字段清洗后进行标准化去重，处理商品编号缺失或变体标识变化的情况。

这种调整并不是无条件地“先去重就一定更好”。如果去重键不可靠，过早去重可能把真实变化误判为重复。因此，我们保留了原始响应和去重决策原因，并对被提前过滤的记录抽样复核。

6. 优化结果与数据质量复核

优化后，同一批 18 万条记录的总耗时从 47 分钟降至 14 分钟，字段清洗从 32.8 分钟降至 7.1 分钟，P99 单条耗时从 640 毫秒降至 118 毫秒。最慢的 1% 记录对总清洗耗时的贡献从 41% 降至 17%。

性能改善并不是单一措施带来的，而是三个动作共同作用：隔离异常长文本、减少重复扫描、提前过滤明确重复数据。更重要的是，优化后异常记录并没有被静默丢弃，而是从主流程转移到了可追踪的异常队列。

六、代码级定位：哪些清洗操作最值得优先检查

1. 重复遍历长字段

同一字段被多个函数依次读取，是最容易被忽略的成本。特别是商品详情、评价摘要和规格描述，这些字段长度差异很大，平均值会掩盖极端样本。

排查时可以搜索同一个字段在清洗链路中的出现次数，记录每次转换前后的长度，并比较函数调用顺序。如果一个字段在四个以上函数中被完整传递，应该评估是否可以合并规则，或者把低优先级处理移到异步任务。

2. 复杂正则处理没有输入边界

正则规则本身不一定危险，危险的是没有输入长度边界、没有超时保护，也没有对异常文本做分流。一个正常字段可能只有 500 个字符，但错误页面可能包含几十万字符，规则的实际执行成本完全不同。

我建议为高成本文本处理增加三道保护：先判断内容类型，再限制最大处理长度，最后对无法识别的结构进入异常队列。截断后的文本不应直接覆盖原始字段，应该明确标记为“标准化摘要”或“部分清洗结果”。

MAX_DETAIL_LENGTH = 12000
def normalize_detail(raw_text):

if not raw_text:

return {

"value": None,

"status": "empty"

}

if looks_like_error_page(raw_text):

return {

"value": None,

"status": "error_page",

"raw_length": len(raw_text)

}

if len(raw_text) > MAX_DETAIL_LENGTH:

return {

"value": lightweight_clean(raw_text[:MAX_DETAIL_LENGTH]),

"status": "truncated",

"raw_length": len(raw_text)

}

return {

"value": standard_clean(raw_text),

"status": "normal",

"raw_length": len(raw_text)

}

这段逻辑的重点不是具体阈值，而是把正常数据、异常页面和超长数据分开处理。阈值应根据业务字段和历史分布确定，并通过字段完整率和告警准确率验证。

3. 循环中重复构造映射关系

有些清洗代码会在每条商品记录内部重新构造币种映射、类目映射、状态映射或字段规则表。单次构造成本很低，但在十万级数据中会被重复执行几十万次。

如果映射关系在一个批次内稳定，可以在批次开始前构造一次；如果映射关系需要定期刷新，可以使用带版本号的缓存。不要为了追求缓存而忽略规则更新，缓存应明确失效时间和版本来源。

4. 循环中使用线性查找

去重和字段归类常常需要判断某个商品编号、变体编号或标签是否已经出现。如果每次都在列表中逐项查找，数据量增长后复杂度会迅速上升。对于只需要判断是否存在的场景，集合或哈希结构通常更合适。

但这里仍然要注意内存边界。一次性把所有历史商品标识加载到内存，可能让去重变快，却造成内存峰值上升。对于长时间运行的任务，应评估分区、批次和数据库临时表方案。

5. 日期、金额和数量的重复转换

价格字段经常经历多次转换：先去货币符号，再去千分位，再识别区间，最后转成数值。如果同一个字段在解析、清洗、校验和入库前分别转换，代码不仅慢，也容易出现不同函数使用不同规则的情况。

建议为关键字段定义明确的标准化边界。例如价格在字段清洗阶段完成一次转换，后续只读取标准数值；如果原始字段存在区间或促销文案，则同时保留原始值、标准值和解析状态，避免后续再次猜测。

七、不同情况下的行动建议：不要用同一套方案处理所有任务

1. 如果瓶颈主要在网络请求

当请求阶段占总耗时超过一半，且清洗单条耗时稳定时，优先检查请求连接复用、并发上限、重试退避、响应缓存和错误页面识别。

• 把连接建立和实际响应等待分开记录。
• 区分限流重试、超时重试和业务错误重试。
• 限制重试次数，避免错误页面反复进入清洗流程。
• 对未变化页面使用条件请求或业务层增量判断。
• 控制并发度，避免用更高并发换来平台限流和内存暴涨。

网络瓶颈下，提高并发可能有效，但必须以错误率、限流率和内存峰值不恶化为前提。请求速度变快不等于任务质量变高，尤其是竞品监控更看重稳定覆盖，而不是单次峰值速度。

2. 如果瓶颈主要在页面解析

解析阶段变慢，通常与 HTML 结构复杂、选择器重复查询、页面中无关节点增多或解析器使用方式有关。可以减少重复选择器调用，先定位父节点，再在局部范围提取字段。

如果页面同时包含结构化接口数据和完整 HTML，应优先使用稳定的结构化字段，HTML 只作为缺失字段的补充来源。不要为了“字段齐全”而每次都解析完整页面。

3. 如果瓶颈主要在字段清洗

字段清洗占比高时，优先执行函数级和字段级剖析，找出慢函数、慢字段和慢样本。一般建议按照“隔离异常输入、减少重复扫描、合并轻量规则、延后低优先级字段”的顺序处理。

• 先给超长字段设置边界和状态标记。
• 把正常路径和异常路径分开。
• 减少同一字段被多个函数完整遍历。
• 将内容分析类字段从实时链路拆出。
• 对关键字段保留原始值和标准化状态。

4. 如果瓶颈主要在去重

先确认去重键是否稳定，再决定是否提前去重。商品编号、变体编号、店铺标识和页面时间都可能参与判断，但不同业务对“同一商品”的定义并不相同。

如果监控目标是价格变化，商品编号稳定时可以先按商品编号和采集时间做轻量过滤。如果监控目标是页面结构变化，则不能仅凭商品编号过滤，因为同一商品的页面内容变化本身就是需要保留的事件。

5. 如果瓶颈主要在写入

只有在清洗输出已经准备完成、写入阶段占主要比例时，才建议检查批量大小、事务范围、索引数量、冲突更新和连接池。可以对比单条写入、小批量写入和大批量写入的吞吐及内存峰值。

不要盲目把批量调得很大。批量过大可能减少数据库交互次数，却增加失败重试成本，也会让单批次内存和事务锁持有时间上升。

6. 如果问题只在少数类目发生

这通常说明输入数据形态存在类目差异，例如某些类目详情更长、规格更复杂，或者页面中包含更多富文本和评价内容。此时不必让所有类目都使用最高复杂度规则。

可以按照类目建立处理策略：普通类目使用标准规则，高复杂度类目使用字段限长和异步深度清洗，结构不稳定类目则增加异常样本采集和规则版本管理。

八、性能优化与数据质量之间的取舍

1. 实时性越高，不代表所有字段都要实时清洗

竞品监控经常同时包含价格告警、库存变化、评价趋势和详情内容分析。它们的更新频率和容错空间不同，应该拆成不同处理层。

2. 截断数据还是延迟处理，要根据用途决定

如果字段用于搜索摘要或趋势判断，截取前若干字符可能足够；如果字段用于合规审核、内容比对或页面变更检测，截断可能损失关键内容，此时更适合延迟处理而不是丢弃。

我通常会同时保存原始值、标准化值、处理状态和规则版本。这样主链路可以使用标准化值，后续发现规则错误时仍然可以基于原始值回放，而不需要重新抓取页面。

3. 提前去重还是完整保留，要看监控目标

如果目标是获得当前竞品价格快照，重复数据没有必要反复清洗，可以提前过滤。如果目标是分析页面变化、促销文案变化或库存波动，重复采集本身可能具有时间价值，不能简单删除。

因此，去重不应该只由技术团队决定。需要先明确业务对象是“商品当前状态”，还是“商品状态变化事件”。前者适合快照去重，后者需要保留变化时间和版本。

4. 批处理吞吐还是异常可追踪性，要根据故障成本决定

把异常数据全部隔离，可以让主任务更快，但异常队列需要有人处理；把异常全部留在主链路，可以保证结果完整，却可能拖慢整个任务。两者没有绝对答案，关键在于异常造成的业务损失。

对于价格告警系统，漏掉一个异常页面可能比延迟几分钟更危险，因此应优先保证异常可见性。对于低频市场趋势分析，允许异常记录在下一轮补偿处理，可以换取更高吞吐。

九、优化验证：证明任务变快，还要证明结果没有变坏

1. 建立固定的回归样本集

回归样本集不应只包含正常商品。至少要覆盖短文本、长文本、空字段、异常价格、多个变体、重复商品、错误页面和页面结构变化样本。

每次规则修改后，都用同一批样本比较标准化结果。字段差异需要分类：预期差异、修复差异、非预期差异。只有非预期差异被解释并接受，优化版本才适合进入生产。

2. 同时比较吞吐、长尾和内存

总耗时下降并不代表系统整体变好。某个优化可能让 CPU 利用率下降，但内存峰值增加；也可能让平均耗时下降，但 P99 变得更不稳定。因此，至少要比较总耗时、平均单条耗时、P95、P99、峰值内存、异常率和输出记录数。

3. 做一次扩容前后的交叉验证

如果优化后仍然需要提高并发或增加机器，应该先在相同样本上做单机对照，再做资源扩容对照。这样可以判断问题是算法效率、单机资源，还是任务调度方式。

例如，单机优化后清洗从 32 分钟降到 8 分钟，扩容后降到 5 分钟，说明算法优化贡献更大；如果单机优化后仍为 30 分钟，扩容后才降到 8 分钟，则可能存在并行化不足或 CPU 资源瓶颈。

4. 用线上数据观察优化是否真正生效

离线样本只能证明代码在固定输入上更快。上线后还要观察至少一周的任务分布，重点看不同类目、不同页面类型和不同时间段是否出现新的长尾。

建议给清洗规则增加版本号，并在日志中保存规则版本、输入类型和异常状态。这样当某天 P99 突然升高时，可以快速判断是页面数据变化还是代码发布导致。

十、建议保留的监控字段与复盘模板

1. 批次级日志字段

• 任务编号、规则版本和运行环境。
• 开始时间、结束时间和批次耗时。
• 输入记录数、有效记录数和输出记录数。
• 请求次数、成功次数、重试次数和错误类型。
• 解析、清洗、去重、写入各阶段耗时。
• 平均耗时、P95、P99和最大单条耗时。
• 空字段数量、格式异常数量和异常队列数量。
• 峰值内存、CPU利用率和并发任务数。

2. 单条慢记录字段

• 商品标识、类目标识、页面类型和采集时间。
• 单条总耗时以及各字段处理耗时。
• 标题、详情、评价和规格字段的长度。
• HTML标签数、数组元素数和嵌套层级。
• 是否命中异常页面、截断规则或重试规则。
• 清洗前后的字段摘要及规则版本。

3. 每次复盘都要回答的六个问题

1. 总耗时增加了多少，增长发生在哪个阶段？
2. 是所有记录变慢，还是少数记录形成长尾？
3. 最慢记录具有什么共同数据特征？
4. 慢字段对应哪些具体函数或规则？
5. 优化后哪些关键字段发生了差异？
6. 异常数据是否仍然可追踪、可补偿、可回放？

如果这六个问题无法回答，就不建议直接进入大规模重构。先补日志、固定样本和建立基线，通常比立即重写清洗模块更节省时间。

十一、下一步怎么做：一份可执行的排查顺序

1. 两小时内完成初步定位

第一阶段不追求解决全部问题，只需要确认瓶颈边界。记录一个完整批次的请求、解析、清洗、去重和写入耗时，并查看 CPU、内存和异常数量。

• 如果请求占比最高，先看重试和限流。
• 如果解析占比最高，先看重复选择器和页面范围。
• 如果清洗占比最高，进入函数级采样。
• 如果写入占比最高，检查批量和索引。

2. 半天内找到最慢样本

在清洗过程中对单条记录采样，至少保留最慢的前 100 条。将它们与正常样本比较字段长度、嵌套结构、异常状态和页面类型。通常这一步就能判断问题是输入复杂度还是全量算法。

3. 一天内完成单变量验证

不要同时修改十处代码。可以依次关闭详情 HTML 清理、关闭评价深度解析、关闭全量去重或改变异常文本处理方式，每次只改变一个变量，再在固定样本上比较耗时和结果差异。

4. 上线前保留回滚与补偿路径

性能优化涉及数据规则时，必须保留旧版本规则、原始响应和异常队列。即使新版本出现字段误判，也能够回放历史数据并重新生成标准化结果。

如果优化只是改变执行顺序，可以逐步放量；如果改变了去重定义、字段截断方式或异常过滤逻辑，建议先针对一个类目或一小批商品运行，再扩大范围。

十二、结语：真正值得优化的不是“清洗代码”，而是清洗决策

竞品监控中的清洗耗时，表面上是一个性能问题，深层上却是数据处理决策问题：哪些字段必须现在处理，哪些字段可以延迟；哪些异常必须阻塞主链路，哪些异常可以进入补偿队列；哪些重复记录可以提前过滤，哪些记录必须保留为变化事件。

我在这类项目中最看重的，不是某个函数快了多少，而是团队能否建立一套稳定的因果链：阶段耗时告诉我们慢在哪里，慢记录告诉我们为什么慢，基准测试告诉我们改动是否有效，数据质量复核告诉我们是否值得上线。

下一步可以从最小闭环开始：给现有任务补齐阶段埋点，固定一批脱敏原始样本，输出最慢的 100 条记录，再用字段长度、异常类型和规则耗时做关联分析。先把“感觉清洗变慢”变成一张可验证的数据表，后续的代码优化、任务拆分和资源扩容才有可靠依据。

如果只能记住一个判断标准，可以记住这句话：不要先问清洗代码怎么改，先问是哪类数据在什么处理阶段制造了多少耗时，以及这部分耗时是否值得保留。

免费注册

咨询方案

扫码咨询方案