变量命名需带业务含义并用下划线全小写，如user_click_log_raw；pd.read_csv()须显式指定dtype和parse_dates；清洗逻辑须封装为单一职责函数；图表代码与分析逻辑必须分离。
变量命名必须带业务含义，不能用 df、data 这类泛称
很多人一上来就写 df = pd.read_csv(...)，后续十几处都用 df，等要加第二个数据源时变成 df2、df_temp，很快自己都分不清哪个是清洗后的用户行为日志，哪个是合并了维度表的宽表。可维护性崩塌往往从第一个模糊命名开始。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用下划线连接的全小写名词短语，如
user_click_log_raw、product_category_mapping - 后缀体现状态：加
_raw（原始）、_clean（已去重/补缺）、_enriched（已关联维度） - 避免缩写歧义，
usr_df不如user_profile_df明确；agg不如daily_revenue_by_region
pd.read_csv() 必须显式指定 dtype 和 parse_dates
不设 dtype 会导致 Pandas 自动推断列类型出错：手机号变成 float、ID 带前导零被截断、分类字段读成 object 后无法高效 .cat.codes。不设 parse_dates 会让时间列变成字符串，后续 .dt.month 直接报 AttributeError。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 提前整理字段类型清单，写进字典传给
dtype=，例如：{'user_id': 'string', 'amount': 'float32', 'status': 'category'} - 时间列名直接传列表给
parse_dates=，如['event_time', 'create_date']，别依赖infer_datetime_format=True - 加
low_memory=False避免混合类型警告干扰 CI 流程
所有清洗逻辑必须封装成函数，禁止在主流程里写 5 行以上链式操作
像 df.dropna().fillna(0).astype(int).pipe(lambda x: x[x > 0]) 这种“一行流”看着简洁，实际调试时没法打断点、没法单独测试、出错时堆栈指向 lambda 而不是具体步骤。多人协作时更没人敢改。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 每个清洗动作独立成函数，命名体现意图，如
drop_invalid_amount_rows(df)、normalize_phone_number(df) - 函数只做一件事，输入输出都是
DataFrame，不修改原对象（inplace=False） - 主流程保持“函数调用序列”，例如：
user_log = user_log_raw.pipe(drop_duplicate_events)\ .pipe(fill_missing_user_ids)\ .pipe(convert_event_time_to_utc)
图表代码和分析逻辑必须分离，禁止在绘图函数里写 groupby 或 agg
把聚合计算塞进 plt.plot(df.groupby('date')['revenue'].sum()) 看似省事，但下次要换指标就得重跑整个流程；想加个置信区间？得拆开再拼。图表应只负责可视化，数据准备由上游函数完成。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 分析脚本里先生成明确命名的结果表，如
daily_revenue_summary = calc_daily_revenue(user_log_clean) - 绘图函数只接收已聚合好的
DataFrame，参数限定为数据 + 样式，如plot_line_chart(daily_revenue_summary, title="Revenue Trend") - 图表函数内部不做任何
merge、filter、agg，只调plt或seaborn接口
df2 = df1.copy() 没写注释，半年后谁也想不起为什么需要这个副本。规范不是约束，是给未来的自己留的线索。 
