一个 44KB 的 Excel 文件,里面拼了三张表

公众号后台有个统计页,能把一段时间的阅读数据导出成一个 .xls 文件——这是官方给的功能,本意是让运营者自己拿去做趋势分析,毕竟后台图表能看的维度太有限,想按自己的口径拆一拆,就只能靠这份导出文件自己跑脚本。这类"导出"按钮在各种后台系统里都很常见,点一下,系统把它数据库里的东西按它自己方便的方式吐给你,至于你拿到手怎么用,它不负责。

之前写过一篇"内容变现看总阅读量还是有效篇数",想把那套统计再往下做一层,按渠道拆开重新算一次,看看到底是哪几个渠道在真正带阅读。这周又点了一次那个导出按钮,拿到一个 tendency_1780451875_1781402275.xls,44032 字节,打开是张叫 New Sheet1 的工作表,135 行 16 列。看着挺规整,脚本一跑,直接甩出一句 TypeError: '<=' not supported between instances of 'float' and 'datetime.date'。心里第一反应是"这才几行数据,能有什么复杂的",没想到接下来折腾了小半天。

脑子里下意识的判断是日期格式有问题,这类报错十次有八次都是这个方向。翻了半天类型转换,改了三四种日期解析方式,错误照样在。真正打开原始文件逐行看才发现,这 135 行 16 列根本不是一张规范明细表,是三段完全不同结构的数据横向拼在同一张工作表里:第一段是日期、渠道、阅读人数;第二段是每日分享、阅读原文、收藏、发表篇数;第三段是传播渠道、发表日期、内容标题、阅读人数、占比。三段之间没有分隔符,只是空列错位挤在一起,我的脚本按"这是一张表"的假设去按列统计,自然把第二段、第三段的表头和空值当成了第一段的日期在读。

报错说的是格式问题,根子其实是我把三张表拼出来的东西当成了一张表——行列对不上号,类型自然对不上号,报错精确地指向了症状,却完全没提根因。

这不是公众号后台一家的毛病。后台系统的"导出"按钮,给的是它内部方便生成的格式,不是为了让你的代码好读,HR 系统导出的花名册、财务系统导出的对账单,经常也是这种多级表头、合并单元格、几段数据挤一张纸的做法——做表的人心里想的是"打印出来给人看",不是"喂给一个统计脚本"。工具默认一个文件就是一张表,大多数时候是对的,少数时候是错的,错的时候,报错永远不会替你说出"这其实是三张表",只会扔给你一个看起来毫不相关的类型错误,把你往错的方向带出去老远。

修法不难,pd.to_datetime(..., errors='coerce') 把读岔的值转成空值删掉,三段分开聚合就行,代码改完五分钟。真正让我在意的是:做自动化这些年,类似的坑踩过不止一次,写系统兜底逻辑时踩过一次,查 AI 抓不到资料还硬编答案时又踩过一次,这次拿到一份"导出"文件,还是下意识先信了它的表面结构,没先打开看一眼再动手。要是这次报错报得温和一点,没这么诡异,我大概率会照着那份被污染的日期列往下算,算出一个看着正常、实际全错的渠道分布,自己还蒙在鼓里。这个习惯,到现在也没真正改掉。