上周把第五章作业交上去，批改意见回到手里的那一刻，我发现助教在代码末尾批了一句：方法都对，但你中间绕过的那几步，恰巧是最值钱的几步。这门课叫数据处理与可视化，第五章作业的题目是“完成一份从原始数据到最终结论的完整分析任务”。学号文件是233810310319，作业本身倒不复杂，但要把整条链路走通，确实踩了不少意料之外的坑。这份作业考察的不是单个函数调用，而是从数据清洗、统计口径、可视化表达到可复现提交的全流程。如果你也正在做类似的数据分析课作业，或者自学到pandas和matplotlib这一阶段，我这篇就当一份踩坑地图给你参考。
1. 第五章作业到底在考什么：一份“从数据到结论”的完整链路
1.1 作业题面与评分标准
题目看起来并不难：给定某城市连续一年的气象观测记录，要求独立完成数据读取、异常值处理、月度和季度统计，并产出至少三张可视化图表，最后写一份简短的数据分析说明。数据是一份CSV，包含日期、最高气温、最低气温、降水量、风向、风速和天气现象这几列，总共有九千多行。
评分标准倒是写得很细。数据预处理占三成，统计计算的正确性占三成，图表质量和可读性占两成，代码结构与注释占两成。这里头有个容易被忽略的暗示，老师要的不只是一张好看的图，而是每一步操作都经得起追问，比如为什么删掉某些行，为什么用均值而不是中位数去填充缺失值，这些决策过程都要能说清楚。我当时一度觉得这个要求太苛刻，后来才发现，这其实就是工作里做数据报告的真实状态。
1.2 为什么课程要设计这样一份作业
前面四章分别讲了pandas基础、数据筛选、分组聚合和matplotlib绘图，第五章作业其实就是把这几块知识串成一条流水线。单独拎出来每个知识点都能跑通，但串起来之后，问题就藏在接口处。举个例子，第四章学groupby的时候，数据都是现成的、规规整整的，可一旦遇到日期列里有空值、气温列里有明显异常，整个分组统计的结果就会悄悄出错。
这种作业设计的真实目的，是逼你面对真实数据的脏乱差。课堂练习里数据是理想的，但现实中的数据往往缺失、重复、格式混乱、量纲不统一。作业里那九千多行数据就是这样，乍一看挺规整，细看全是需要做决定的细节。做完这份作业我才意识到，课程作业不是考你会不会调包，而是考你面对一团乱麻时有没有一套自己的处理套路。
2. 选数据与初探阶段：最先遇到的三个坑
2.1 数据源选型：不要一上来就选“太干净”的数据
我前两次尝试用的都是可以从公开渠道下载的示例数据。第一份数据只有一千多行、字段也少，清洗起来轻松，但做出统计之后根本讲不出什么有价值的结论。第二份数据倒是大而全，但有十几个字段，很多列对我来说根本用不上，反而增加了理解和处理的负担。
后来我换了思路：选一份恰好包含时间、气温、降水这几类核心字段、行数在几千到一万之间、存在少量缺失和记录错误但没有严重结构性问题的数据。这种颗粒度的数据刚好能体现处理过程，又不至于让人陷进数据修复的无底洞。如果行数太少，异常值和缺失很难体现统计意义；如果字段太多，又会分散注意力，偏离作业要考察的主线。经验之谈，作业阶段千万别选那种几个GB的大数据集，纯属给自己添堵。
2.2 编码与日期解析：第一个拦路虎
读取CSV这个步骤，正常情况下几行代码就完事，但我第一次读的时候直接报了一串解码错误。原因很简单，这份数据用GBK编码保存，而pandas的read_csv默认按UTF-8尝试解析。解决方式也直接：读取时把encoding参数指定为gbk，或者加errors参数做容错处理。
日期列的解析则是另一个容易翻车的点。原始数据里的日期长这样：2024/1/5、2024/1/15，本来以为pd.to_datetime一把梭就行，结果因为数据里有几行日期格式不统一，比如有“2024-1-5”和“20240105”这样的变体，导致部分记录被解析成缺失值。后来我统一用parse_dates参数在读取阶段处理，并指定format，能极大提高解析稳定性。
顺带提一个当时没注意到的问题：如果不指定格式，pandas在解析大文件时会反复猜测日期格式，速度慢不少。处理这类小文件还好，将来数据量一大，这个时间差会非常明显。所以从一开始就养成指定日期格式的习惯，后面能省很多事。
2.3 数据概况的快速体检
读进来之后，我先做了一次数据概况的摸底，不是直接开始清洗，而是先看清这份数据到底长什么样。具体操作就三件事：看shape确认总行数和列数；看info看每一列的非空计数和数据类型；看describe查看数值列的均值、标准差、最小最大分位数。
这三个操作能快速暴露很多问题。比如我发现“风速”列只有八千多个非空值，缺失率大概接近百分之八；而气温字段出现了几个极端值，最低气温有-40度的记录，对一个不算偏北的城市来说明显异常。最需要留意的是describe结果里各列数据口径是否统一，有些项目风速单位可能是米每秒，也可能是千米每小时，一旦没注意到，统计出的“平均风速”数字会让人误判。这一步帮我确定了后续清洗的重点区域。
3. 清洗环节的手工操作与取舍思路
3.1 对缺失值动手之前先问三个问题
数据清洗最容易犯的错误，是一拿到缺失值就默认填充或删除。我一开始也这样，遇到NaN就fillna，后来发现两个问题：一是填充方式会直接影响统计结果，二是有些缺失本身包含信息。
处理缺失值之前，我先问了三个问题：第一，缺失率有多高，低于百分之一的行可以直接删，高到百分之三十就必须仔细考虑；第二，缺失发生在哪几列，如果是关键字段（比如气温）缺失，删除比填充更稳妥，如果是次要字段（比如风向）缺失，可以用合理方式处理；第三，后续分析到底用不用得到这一列，用不到就暂时不管。
这份气象数据里，“降水量”列有少量缺失，而且集中分布在某几个月份，直接删行会让这几个月的样本量明显减少。后来我采用的做法是：气温类字段的行缺失直接删除，降水量的缺失用相邻日期的平均值做填充，并在说明文档里写清楚我这个选择的理由。这是整个作业里我认为最关键的一个决策点，因为填充策略直接决定了后续统计结果。
3.2 异常值剔除的边界怎么划
气温字段有几行明显不符合常理，我一开始想当然地认为超过三倍标准差就是异常值。可这份数据的气温分布并不是正态的，夏季和冬季的温差天然就大，用3σ法容易把真实的高温或低温记录也一起删掉。实际处理时我改用了IQR（四分位距）方法，以数据的五数概括为基础，把低于Q1-1.5IQR或高于Q3+1.5IQR的记录标记出来，再逐一查看。
标记后逐个检查，我发现大部分确实是录入错误，比如最高气温低于最低气温的行，这明显不合逻辑，直接删除。还有一行降水量达到了800毫米，远超正常范围，这类值如果保留，统计结果会被严重拉偏。与其机械地按规则删除，不如把规则当作提醒，再做一次人工判断。这也算处理经验里比较通用的一条：规则用来筛出可疑点，而不是直接判死刑。
3.3 派生列：把后面分析要用的字段一次造齐
我先不管最终要画几张图，先把可能用到的派生列都建好，免得分析到一半再回去改。具体造了几个字段：从日期中拆出年份、月份、星期，计算了当天的温差（最高温减最低温），把月份映射到季节。
这些派生字段花不了几行代码，但后面的分组统计会频繁用到。造字段的过程也对了一遍数据里的星期逻辑，比如2024年的第一天是星期几，验证结果和真实日历一致，避免后续时间分组的偏差。还有一点值得注意，日期的排序问题在造派生列时必须处理掉，如果原始数据并不是按时间顺序排列，后面画折线图时线条会来回折，必须先sort_values再重新设置索引。
4. 统计分析口径：从描述统计到分组聚合
4.1 日期分组的惯用手法：groupby与resample
统计部分我用到了两种分组方式，一种是pandas里的groupby加月份，一种是resample按时间频率聚合。两种方法在结果上很接近，但细节上有差别。groupby适合按独立的时间字段（比如月份列）分组，resample更适合直接在DatetimeIndex上做时间频率聚合。
我分别跑了两遍，比如月度平均气温，groupby方式用df.groupby(['year','month'])['temp_avg'].mean()，resample方式用df.set_index('date').resample('M')['temp_avg'].mean()，得到的结果在数值上几乎一样，但索引结构不同。后来报告里我统一采用了groupby的方式，因为它返回的DataFrame更容易和其他统计指标拼接到一起。resample也不是没用，在检查数据是否按照预期覆盖完整时间段时特别好用，比如连续月份数量对不对、是否有整月缺失。
4.2 环比与同比的“口径陷阱”
统计计算里最容易出问题的不是函数不会写，而是统计口径说不清楚。我看不少同学的作业里写了“年平均气温”和“月平均气温”，但到底每个月有三十天还是三十一天、二月是二十八天还是二十九天，这些细节很少有人交代。
我为了算清楚月度气候特征对比，还做了一张逐月气温统计表，里面除了平均值还有最高值、最低值和降水总量。做完之后发现一个有意思的现象：某个月的降水总量虽然很高，但降水日数并不多，说明这个月的降水可能集中在少数几天。如果没有把“总量”和“日均值”放在一起看，很难发现这层信息。统计口径这块我最后经验是：自己私下怎么算都行，但交上去的每一张表、每一张图都必须标注清楚口径，比如“月均气温=当月每日平均气温的算术平均”这种说明，能避免被批改时误解。
4.3 在代码里保留一份分析逻辑说明书
统计阶段另一个让我尝到甜头的操作，是把每一步的思考以注释形式留在代码里。不是那种一行“计算平均值”的废话注释，而是说明为什么要这样做的决策笔记。比如“这里填充缺失值是因为该月份样本量本身偏少，删除会让月度平均失去代表性”，这种注释帮我在写报告时省了大量回忆时间。
刚开始学数据分析的人都容易有一种错觉，觉得注释是写给别人看的，其实注释最大的受益人是未来的自己。我隔了三天再去改这份作业的代码，如果没有注释，根本记不清当初为什么用IQR而不是3σ。作业题面里“代码结构与注释占两成”这个评分点，其实就是在培养这个习惯。养成每段逻辑配一句决策理由的习惯，无论应付作业还是日后工作，都很值。
5. 可视化阶段：从默认参数到能上交的程度
5.1 图表中文乱码：matplotlib的经典拦路虎
第一次用matplotlib画图，所有中文标签都显示成了方框，我在终端里check了半天才想起来，matplotlib默认的字体里根本没有中文字形。这个问题的解法因系统而异，我在脚本里直接指定了系统中文字体。要注意的是，字体名在不同操作系统下叫法不同，写代码之前先用font_manager查看本机可用字体列表，比反复试错要优雅得多。
设置中文字体只是一个开始，还有负号问题。气温数据里有零下的值，坐标轴的负号可能显示成方块，需要把axes.unicode_minus这个参数设为False。这两个配置我后来统一放到了绘图模块的开头，所有图表共用一份字体配置，省得每张图重复设置。一个小提醒：如果在Notebook环境里改完字体后不重启内核，有时渲染不出来，如果遇到这种情况可以先重启一下。
5.2 折线图、柱状图和散点图的调优过程
作业要求至少三张图，我选了逐月平均气温折线图、季节降水量柱状图和最高气温与降水量散点图三个方向。折线图第一个版本画出来像锯齿一样，因为数据点之间连线的顺序乱了，原因是数据没排序。把数据按时间排好序之后，图形立刻顺眼很多。另一个问题是折线图x轴的刻度太密，十二个月份的标签叠在一起，我设置了每隔两个月显示一个标签，图面立刻清爽。
柱状图的问题出在“季节”顺序上。如果不手动指定分类顺序，pandas会按字母序排序，春季、冬季、秋季、夏季这样排，视觉上很难受。我处理方法是把季节列转成category类型，再按自然顺序设定category顺序，画图时的bar顺序就正常了。散点图的问题则是最低气温和降水量量纲差异大，如果硬画在同一张图里，必须用双y轴，否则降水量会被压成一条贴着横轴的直线。
5.3 让图表“自解释”：标题、单位、数据来源
图表做出来之后，我先问自己一个问题：不看任何注释，单独看这张图能看懂吗？如果答案是不能，说明图本身不合格。于是我给每张图都加了完整的标题、坐标轴标签、单位、图例，以及数据来源的小标注。
加数据来源这件事很多人容易漏，但它其实挺重要。作业要求可信，图表里写明“数据来自某公开气象数据集，选取其中2024年1月1日至2024年12月31日记录”，读者就不用再去猜数据的范围。还有一个小细节：所有图片我统一设置了dpi和图片尺寸，保证在作业文档里缩放后依然清晰，不会出现模糊或比例失调。
6. 提交前的一小时：检查清单与最终打包
6.1 把脚本从“能跑”变成“能复现”
作业交上去之前，我照着“换一台电脑是否还能跑出相同结果”这个标准检查了一遍。首先确保所有文件路径都是相对路径，不能在代码里写死某人的绝对路径。其次把数据文件和脚本放在同一个目录层级，README里写明运行方式。
运行环境也要写清楚。我在报告里列了Python版本、pandas版本和matplotlib版本，并生成了一个requirements.txt，虽然课程不强制要求，但交作业时附上这个文件能避免很多“在我电脑上可以跑”的争议。这一步看起来琐碎，但养成习惯后，做任何项目都能从中受益。
6.2 作业文档结构与命名规范
按课程要求，提交文件名包含学号233810310319和课程信息，但我没有直接拿原始文件名交上去，而是把最终提交的目录整理成三层：数据原始文件、处理脚本、输出报告及其图片。这个结构是为了让批改者能按顺序复现整个流程。
报告本身用Markdown写的，开头是数据来源和字段说明，接着是清洗过程、统计结果、三个核心发现的讨论，最后是结论与不足。写“不足”这块其实也重要，比如我承认数据缺失值处理方式有一定主观性，这种坦诚反而能体现出对数据分析的理解。整份报告控制在三页以内，图和表都嵌在关键论述旁边，没有堆砌一堆输出。
6.3 复盘：这门课留给我的三个习惯
交完作业之后，我给自己做了一次复盘。第一条收获是，处理任何数据之前先做概况检查，绝不跳过info和describe直接开干。第二条，是每个清洗操作都要有站得住的理由，并且写进注释。第三条，是图表标题和轴标签必须完整，能让图脱离代码独立存在。
这三个习惯后来帮我做了几份课程之外的分析任务，发现它们同样适用。数据项目的成败往往不取决于某个高深的算法，而取决于每个小环节上是否做了足够的思考和记录。如果你也卡在类似的作业上，我的建议是先别急着写代码，先把数据从头到尾看一遍，想清楚每一步为什么这么做，再动手整理你的完整处理流程。这样下来，一份作业能学到的东西绝对不止分数那么简单。
