Python量化交易：玩转Pandas——金融数据清洗与时间序列分析实战

先说个真实经历。前两年我写过一个自认为很完美的均线策略，回测曲线漂亮得让人心跳加速，年化、回撤、夏普全都很能打。结果换了一台机器、换了一个数据源重新跑，收益直接腰斩，信号数量也少了三分之一。查了两天，最后定位到的问题特别蠢：我从两个接口拉的数据，一只股票的前复权因子不一致，导致计算出来的均线在某个时间段发生了莫名其妙的跳变，策略在那个区间频繁开平仓，把净值曲线拉出了一堆锯齿。

类似这样的坑，我在做量化交易的过程中踩过太多了。所以今天想认真聊聊Pandas在金融数据清洗与时间序列分析里的实战用法。这几个字看起来简单——无非是read_csv、dropna、to_datetime、resample——但真正决定策略稳定性的，恰恰是这些基础操作背后那些容易被忽略的细节。这篇文章会从数据清洗开始，一直讲到时间序列索引、重采样、滚动计算和性能优化，最后给出一套可复用的处理流水线。适合已经会用Python跑通简单脚本、正在往量化方向进阶的读者，也适合那些拿着现成策略源码但不知道数据为什么对不上的朋友。

1. 金融数据清洗为什么是量化的第一道生死线

很多刚接触量化的人以为策略的核心是选股逻辑或者参数优化，但以我的实际经验来看，真正让一个策略从“回测能看”走向“实盘可用”的，恰恰是数据处理这个环节。模型再精巧，喂进去的数据是脏的，输出的信号就是噪音。下面拆几个最常见的污染路径。

1.1 脏数据对回测结果的污染路径

金融数据里的脏数据不是“格式不对”那么简单，它会直接制造出假的收益。最典型的就是未来函数。比如你从某个接口下载的日线数据里，某一天的“收盘价”字段在当天收盘前就被填充了，或者复权因子在历史某天发生了跳变，导致你用当日数据计算出的信号，实际上包含了次日甚至未来几天的价格信息。回测时这些信号看起来神准，实盘一跑就露馅。

另一个常见问题是幸存者偏差。如果你用的是某个快照式的成分股列表，而不是当时时点的成分股数据，那么被退市、被ST的股票会在历史回测中完全消失，剩下的都是“活下来的赢家”，策略收益自然虚高。这两类问题用Pandas很难直接检测，但通过清洗步骤中的数据版本标注、因子对比和区间抽检，能很大程度上规避。

1.2 量化场景下“干净数据”的三个标准

做量化数据清洗不能只盯着“有没有空值”，而是要建立三个更高维度的标准。

第一是对齐性。多只股票的数据必须按照同一个交易日历对齐，A股有春节、国庆长假，港美股又有各自的节假日，如果直接把两个市场的K线横向拼接，时间轴根本对不上。第二是连续性。股票停牌、退市、新上市都会造成K线中断，必须明确这些中断的位置，避免在计算滚动指标时把“不存在的交易日”当作“价格没变”。第三是可比性。分红、送转、配股会改变股价的绝对值，不同股票的复权方式不同，算横截面排名的时候必须统一口径。

这三个标准，单靠dropna和fillna解决不了，需要在构建清洗流水线的时候主动设计进去。

1.3 数据源的差异：不要把一个接口用到老

现在获取金融数据的渠道非常多：tushare、akshare、baostock、聚宽、米筐、QMT，有些券商的行情接口也开放了历史数据。但同样一只股票、同一天的K线，不同数据源给出的数值可能不一样，差异主要来自复权算法、除权除息时间点、以及缓冲区里的延迟数据。我的建议是：选一个主数据源做主回测，另一个独立数据源做交叉验证。每次处理完数据后，随机抽几只股票，对比两个源的OHLCV和成交量，如果偏差超过千分之一，说明有字段解析或复权逻辑的问题，优先排查。

2. 重复值、缺失值与异常值：三个最常见的脏数据场景

这是清洗操作最密集的部分，也是网上教程最容易一笔带过的地方。下面我按照实际处理顺序，把每一类问题的方法和原理说透。

2.1 重复值处理：不是简单drop_duplicates就完事

数据重复通常有两种情况。第一种是接口重试或者下载时断点续传导致的完全重复，整行一模一样，直接drop_duplicates()就行。第二种是业务层面的重复，比如同一只股票在某一天出现了两条记录，一条是盘中临时数据，一条是收盘后的确认数据，两者在成交量上会有微小差异。这种就不能盲目去重，需要按“业务键 + 时间戳”去判断。

在A股日线场景下，业务键通常是ts_code + trade_date。标准做法是这样：

python复制import pandas as pd

df = pd.read_csv('daily_raw.csv', dtype={'ts_code': str})
# 先按业务键排序，权重高的数据源/字段优先级排后面
df = df.sort_values(['ts_code', 'trade_date', 'update_time'])
# 保留每个业务键的最后一条记录
df_clean = df.drop_duplicates(subset=['ts_code', 'trade_date'], keep='last')

这里有个关键点：sort_values可以把update_time较晚的记录排到最后，然后keep='last'就能保留最新版本。如果你的数据里没有update_time这类版本字段，至少要保留一个“数据来源优先级”字段来做排序，否则去重后保留哪条就是一个黑盒，后面出了问题很难追溯。

2.2 缺失值处理：停牌导致的NaN不能乱填

Pandas里fillna和ffill用起来很简单，但在金融数据里，缺失值必须区分“为什么缺失”。

股票停牌、新股上市前、退市整理期，这些场景都会产生NaN。比如某只股票停牌一天，当天的开盘、最高、最低、收盘全是NaN。如果直接ffill()把价格填成前一天的收盘价，那么后续计算收益率时，这一天会被当成“涨跌幅为0”，这本身没错——停牌时持仓市值确实不变——但如果你用的是pct_change()计算收益，然后拿去算波动率或夏普比率，0收益样本会把波动率显著拉低，让风险指标失真。

更稳妥的做法是填值的同时打标记。新增一列is_suspended或者is_filled，并在后续分析里单独处理这些样本：

• 计算波动率时，可以把停牌日的收益改成NaN，让rolling.std()按实际交易天数计算；
• 计算因子信号时，若某个因子依赖前N日收益率，而中间有停牌日，要决定是跳过（用min_periods）还是用limit=N的前向填充。

常见操作示例：

python复制# 只前向填充最近3个交易日，避免把很久以前的价格填到新股票上
df['close'] = df['close'].ffill(limit=3)
df['is_filled'] = df['close'].isna().astype(int)

这里limit=3的意思是每个缺失值最多由前3个有效值往前填充一次，如果一只股票连续停牌超过3天，填充后的价格仍然是NaN，这样后续计算就不会误伤。

2.3 异常值处理：别用普通数据集的z-score方法

互联网行业做异常检测喜欢用z-score，但在金融收益率序列里，这一招默认就是错的。金融数据是典型的重尾分布，一天跌5%在大多数时候是极端情况，但在市场恐慌阶段可能连续多天都是“-5%以上”，如果按z-score算，这些真实行情会被当成异常值直接剔除，等于把策略最需要捕捉的极端行情给抹掉了。

我的做法是优先处理物理不可能的异常：

• 价格为负或为0，直接剔除；
• 当日涨幅超过交易所涨跌停限制（主板±10%、创业板/科创板±20%、北交所±30%），并且不是除权日，优先怀疑数据解析错误，做标记后人工抽检；
• OHLC关系中最高价小于最低价，或者收盘价不在最高最低区间内，直接剔除。

对于统计层面的极端值，我会用MAD（中位数绝对偏差）而不是标准差来识别：

python复制import numpy as np

def mad_outlier(series, n=5):
    med = series.median()
    mad = (series - med).abs().median()
    if mad == 0:
        return pd.Series(False, index=series.index)
    modified_z = 0.6745 * (series - med) / mad
    return modified_z.abs() > n

MAD比标准差更稳健，对重尾分布不敏感，适合处理涨跌停极值、瞬间拉涨拉跌这些情况。识别出来之后，我通常不是直接删掉，而是用前后两个交易日的均值做一个平滑填充，并且在status列里标记为outlier_adjusted，保持数据的可审计性。

3. 数据类型与字段约定：隐含的错误比显性的缺失更危险

这个章节很多教程不提，但在实际项目里，我遇到过太多次因为字段类型不对导致的计算错乱。

3.1 时间字段：to_datetime的正确打开方式

最常见的坑是交易日期被读成了字符串或者整数。tushare老接口返回的trade_date是int类型，比如20240105，而akshare返回的可能是datetime.date类型。如果直接传给set_index，pandas会把它们当成普通索引，排序是按数值排而不是按日期排，后续resample根本没法用。

标准处理是先统一转成datetime64：

python复制df['trade_date'] = pd.to_datetime(df['trade_date'], format='%Y%m%d')
df['datetime'] = pd.to_datetime(df['trade_date']) + pd.to_timedelta(df['trade_time'].astype(str).str.zfill(6).str[:2].astype(int), unit='h')

这里解释一下：分钟线数据的trade_time可能是int类型的145700代表14:57:00，直接to_datetime会失败。要先转成字符串、补零到6位、取前两位作为小时，再用pd.to_timedelta加到日期上，才能得到一个完整的时间戳。

另外，时区问题在港股、美股和加密货币数据里很常见。同一根K线，不同平台可能给的是UTC时间或本交易所本地时间。跨市场合并数据时，我习惯统一先转成UTC，再用tz_convert转换到目标时区，避免夏令时切换导致的时间错位。

3.2 数值字段的精度与对象类型陷阱

Pandas读CSV时，如果某列里掺杂了一个空字符串或一个"--"，整列会被推断成object类型，之后df['close'].astype(float)会直接报错，很多人在这里卡住。

正确做法是读入时就用dtype参数指定类型，同时对非数值占位符做统一处理：

python复制df = pd.read_csv(
    'daily.csv',
    dtype={
        'ts_code': 'string',   # 股票代码必须是字符串，否则000001会被读成1
        'open': 'float64',
        'high': 'float64',
        'low': 'float64',
        'close': 'float64',
        'vol': 'float64',
    },
    na_values=['', '--', 'NULL', 'None']
)

ts_code用'string'而不是str，这是pandas 1.0之后引入的扩展类型，在后续groupby时性能更好，而且不会出现'object'类型的隐式陷阱。金融数据的股票代码，比如600000.XSHG，如果不用string类型，极容易被当成浮点数或整数截断，这个细节很要命。

3.3 复权因子：回测和历史分析必须统一

关于前复权和后复权，我在这里多说两句。前复权是以“当前价格”为基准，把历史价格按复权因子往下调整，优点是当前价格跟真实行情一致，缺点是每次除权除息后，整段历史价格都会被重新计算一遍，历史回测结果会变化。后复权是以“最早价格”为基准，历史价格不随新除权而改变，适合做长期的收益率计算和因子回测，但当前的绝对价格和真实行情对不上。

我的习惯是：因子计算和回测统一使用后复权价格，只有实盘交易时换算成实际价格。这样能避免“策略信号随复权基准漂移”的问题。处理逻辑如下：

• 从数据源拿到adj_factor（复权因子）字段，若没有，就根据除权除息公告自己计算；
• 后复权价格 = 原始价格 * 复权因子；
• 前复权价格 = 后复权价格 / 最新复权因子。

这里强烈建议不要直接用数据源提供的qfq或hfq字段作为唯一字段，而是保留原始价和复权因子两个字段，这样在需要切换复权口径、或者做数据交叉验证时，能自己随时算。

4. 时间序列索引：对齐、采样与滚动计算

数据清洗完之后，下一步就是把DataFrame变成一条真正的时间序列。

4.1 从date列到DatetimeIndex：不只是set_index

set_index之后，还需要sort_index()，否则索引的时间顺序是乱的，rolling和pct_change都会按行顺序计算，结果完全错误。这个步骤看起来多余，但真实数据从CSV读进来，顺序不一定保证，尤其是多标的拼接后的数据。

标准做法是：

python复制df = df.set_index('trade_date').sort_index()
# 检查时间频率是否一致
print(df.index.freq)  # 如果输出None，说明索引上有缺失
df = df.asfreq('D')   # 统一到日频率，注意这会产生NaN

金融K线数据的索引通常不连续（周末、节假日），df.index.freq往往返回None。这不影响大多数操作，但如果你要用shift、diff这类需要明确时间步长的操作，建议想清楚默认的“行偏移”是不是你想要的。默认shift(1)是“上一行”，而如果数据里有停牌导致的行缺失，这个“上一行”可能是3天前，而不是昨天。

4.2 asfreq 与 resample：重采样时要选对聚合方式

asfreq只负责改变时间频率并用NaN填充缺失值，resample则能做聚合计算。把5分钟线合成日线的时候，聚合逻辑必须是：open取第一个、close取最后一个、high取最大、low取最小、volume求和。如果一股脑全用mean()，合成出来的K线就是错的。

python复制ohlc_dict = {
    'open': 'first',
    'high': 'max',
    'low': 'min',
    'close': 'last',
    'volume': 'sum',
    'amount': 'sum'
}
daily = minute_df.resample('D').agg(ohlc_dict).dropna()

这里有个细节：分钟线的datetime索引包含了时分秒，resample('D')会默认按自然日聚合。但A股夜盘期货的交易时间跨天，晚上21:00的K线属于次日的交易时段，直接按自然日聚合会切成两截。处理夜盘时，我通常会先手动把交易时段映射到“交易日归属”，再加一列trade_date字段，按这个字段聚合，而不是直接resample('D')。

4.3 rolling 与 shift：因子计算最容易出未来函数的地方

说到未来函数，rolling和shift是重灾区。

rolling(20).mean()计算的是截至当前行（含当前行）的20个数据均值，这本身没问题，但如果你的信号是“收盘后判断”再在“次日开盘”执行，那么计算因子时就必须排除当根K线的数据，即用close.shift(1).rolling(20).mean()。

举一个标准因子计算的例子——动量因子：

python复制# 错误：使用了当前收盘价，等于在盘中就能知道收盘价
df['mom_wrong'] = df['close'] / df['close'].shift(10) - 1

# 正确：用截至昨收的动量，信号用于今日开盘或今日收盘后决策
df['mom_correct'] = df['close'].shift(1) / df['close'].shift(11) - 1

再比如均线金叉信号，很多人直接这样写：

python复制df['ma_fast'] = df['close'].rolling(5).mean()
df['ma_slow'] = df['close'].rolling(20).mean()
df['signal'] = (df['ma_fast'] > df['ma_slow']).astype(int)

这段代码的回测结果里，signal是在当前bar收盘后计算的，如果数据是日线，那么在当天收盘价确定之前，这个信号并不存在。回测引擎若用同样的收盘价作为“信号触发价”和“成交价”，会在收盘价这一个价位上完成“计算信号 + 成交”两个动作，这就引入了轻微的未来函数。

解决方法是把信号整体往后挪一根bar，让它作用到下一根bar的开盘价上：

python复制df['signal_shifted'] = df['signal'].shift(1)

这个shift(1)的本质是“信号只能在下一根bar成交”，我建议把它作为回测数据准备阶段的一个标准动作，而不是靠回测引擎去处理。

4.4 截面数据：多标的的MultiIndex操作

如果你处理的是多只股票的面板数据，常见结构是MultiIndex (ts_code, trade_date)。这时操作需要区分“时间序列维度”和“横截面维度”。

python复制df = df.set_index(['ts_code', 'trade_date']).sort_index()

# 按股票分组，计算每只股票自己的滚动收益率
df['ret_20'] = df.groupby(level=0)['close'].pct_change(20)

# 在横截面上做排名：同一交易日，所有股票的20日收益排名
df['ret_20_rank'] = df.groupby(level=1)['ret_20'].rank(pct=True)

这里level=0是ts_code，level=1是trade_date。第一次groupby(level=0)是按股票分组做时间序列操作；第二次groupby(level=1)是按交易日分组做横截面排名。很多人会搞反，导致算出来的排名混入了时间维度，因子分析全乱。

5. 性能优化：数据量大之后Pandas怎么扛住

当你从日线级别升级到分钟级别，或者把股票池扩大到全市场5000多只股票，Pandas的默认操作会变得非常慢。这里分享几个我实测有效的优化方向。

5.1 尽量使用pandas 2.x + PyArrow

Pandas 2.0之后，引入了基于PyArrow的后端，字符串和数值运算性能提升明显，尤其在read_csv、groupby和merge场景下。安装方式是：

bash复制pip install "pandas[performance]" pyarrow

然后在读数据时这样指定dtype后端：

python复制df = pd.read_csv('daily.csv', dtype_backend='pyarrow', engine='pyarrow')
df['close'] = df['close'].astype('float64[pyarrow]')

这里的float64[pyarrow]是PyArrow支持的类型，在groupby和rolling时都比普通float64快。另外，对于重复文本较多的列，比如ts_code和industry，使用dictionary类型能大幅压缩内存：

python复制df['ts_code'] = df['ts_code'].astype('string[pyarrow]')

Pandas 2.x还改进了copy_on_write的默认行为，链式赋值导致的SettingWithCopyWarning会少很多，但依赖“隐式视图修改原数据”的代码，比如df[df['x']>0]['y'] = 1，现在会直接不生效或报错。建议新项目直接开启：

python复制pd.options.mode.copy_on_write = True

5.2 不要用iterrows，向量化优先

用iterrows遍历几百万行做逐行逻辑，是性能杀手。绝大多数逐行逻辑都能改写成向量化操作。最经典的例子是构建交易信号：

python复制# 慢：逐行判断
signals = []
for i, row in df.iterrows():
    if row['ma_fast'] > row['ma_slow']:
        signals.append(1)
    else:
        signals.append(0)
df['signal'] = signals

# 快：np.select
import numpy as np
cond1 = df['ma_fast'] > df['ma_slow']
cond2 = df['ma_fast'] <= df['ma_slow']
df['signal'] = np.select([cond1, cond2], [1, 0], default=np.nan)

如果逻辑真的复杂到无法向量化，可以考虑apply，但要注意它返回的是Series，最好在“无法避免逐行处理”的场景才用。实测下来，np.select比apply快5-10倍，比iterrows快几百倍。

5.3 内存估算与分块读取

处理全市场分钟线数据时，内存会迅速飙升。可以用df.info(memory_usage='deep')查看内存占用。如果超过物理内存的一半，建议用分块读取：

python复制chunks = pd.read_csv('minute_data.csv', chunksize=1000000, dtype=dtype_dict)
processed_chunks = [process_chunk(chunk) for chunk in chunks]
df = pd.concat(processed_chunks, ignore_index=True)

分块处理适合可以并行计算的清洗逻辑，但要注意：resample、rolling这类跨块操作需要额外加缓冲区，或者先把数据按股票代码分组落盘，再逐组处理。对于单只股票的全历史分钟线，单块就能装下，不需要跨块缓冲。

另一个重要的性能技巧是：处理完的数据尽量保存成parquet格式，而不是CSV。parquet是列式存储，读入时只加载需要的列，速度比CSV快几倍，而且自带压缩。

python复制df.to_parquet('daily_clean.parquet')
df = pd.read_parquet('daily_clean.parquet', columns=['ts_code', 'trade_date', 'close', 'volume'])

如果你还需要给其他系统提供数据，比如feather格式，df.to_feather('daily_clean.feather')也是好的选择，它读写速度比parquet更快，但不支持按列选择时跳过非目标列（实际上是整列读入后再过滤的），所以如果是频繁列裁剪场景，parquet更合适。

6. 从清洗到回测的衔接：一套可落地的处理Pipeline

这部分是我最想分享的。清洗代码散落在各种Notebook里没问题，但如果你要稳定跑回测，必须把它整理成一条可复用的流水线。

6.1 标准清洗流水线的分层设计

我习惯把流程拆成四层：

1. 原始数据层：从各种数据源下载的原始CSV或parquet，不修改，只做归档；
2. 清洗层：完成去重、去缺失、类型转换、复权，输出daily_clean.parquet；
3. 特征层：基于清洗后的数据计算各种因子和技术指标，输出features.parquet；
4. 信号层：基于特征生成交易信号，输出signals.parquet。

每一层都加上data_version字段，比如schema_v1、reprocess_20250101，保证可追溯。实际项目里，我至少碰到过3次因为“数据更新了但没注意复权基准变化”导致回测结果波动的情况，版本字段能帮你快速定位是哪一批数据处理出的问题。

6.2 数据校验：清洗完不等于数据对

清洗完数据之后，强烈建议做一轮自动化校验：

• 检查索引是否单调递增、是否无重复；
• 对每只股票，检查low <= close <= high、low <= open <= high；
• 检查复权后的价格是否全部为正；
• 检查时间跨度是否符合预期，比如日线2020年应该有约242个交易日；
• 随机抽取3只股票，和另一数据源做交叉对比，计算最大偏差。

校验代码可以写成独立的函数：

python复制def validate_ohlc(df):
    errors = []
    if not df.index.is_monotonic_increasing:
        errors.append('索引非单调递增')
    if (df['low'] > df['close']).any():
        errors.append('存在low大于close')
    if (df['high'] < df['close']).any():
        errors.append('存在high小于close')
    if (df['close'] <= 0).any():
        errors.append('存在非正收盘价')
    return errors

这些校验逻辑看起来基础，但能挡掉绝大多数“清洗代码写错”的问题。每次修改清洗规则后跑一遍，能省下大量定位脏数据的时间。

6.3 与实盘系统的字段对应

如果你后面要接入QMT、掘金、米筐这类实盘/仿真交易接口，清洗后的字段名和它们的标准字段最好提前对齐。A股常见的标准字段包括：

实盘下单时，我建议把“信号数据”和“成交数据”彻底分开：信号数据用后复权价计算，下单用真实价格，中间通过adj_factor / 最新因子换算。这个换算如果放在回测层完成，实盘时会少很多麻烦。

6.4 回测中“最后一根bar”的边界问题

回测引擎处理数据时，最后一行往往是最容易出问题的地方。比如某策略在最新bar上生成了信号，但此时数据还没收盘，价格还在变动，如果信号中包含close、high、low这类当日未定数据，就隐式地用了未来信息。

处理办法是：在信号生成时，强制把最新一根bar的“未完成”字段标记为NaN，或者直接从信号数据里剔除最新bar。我一般会在数据流水线的最后一步，统一执行：

python复制# 假设df是特征数据，包含了当前正在形成的bar
latest_trade_date = df.index.get_level_values('trade_date').max()
df = df[df['is_completed'] == 1]  # is_completed列由数据源标记

如果数据源没有is_completed字段，就按交易所规则判断：日线数据只有过了收盘时间才算complete，分钟线数据只有当前分钟结束才算complete。这一层校验能在回测和实盘之间建立一条安全边界。

7. 几个实操中容易忽略的细节与踩坑记录

最后这部分，我把这几年写量化数据代码过程中踩过的几个印象深刻的坑，集中写出来。

7.1 不同数据源的“收盘价”定义不一样

A股日线收盘价是集合竞价后产生的最后成交价，但有些数据源的日线close其实是“最后一笔成交价”，个别时候和交易所官方收盘价有细微差别，尤其遇到尾盘瞬拉瞬砸的时刻。处理方式有两个：一是尽量从交易所官网或者付费数据源取官方收盘价；二是如果数据源只有官方行情，就固定用一个源，别混着对比不同源的收盘价。做日内策略，尤其需要注意这一点，因为分钟线最后一根bar的close和官方收盘价经常不一致。

7.2 涨跌停日和停牌日的假信号

某只股票涨停了，价格封死不动，成交量极度缩小。这时候用“价格不变、量缩”的规则去识别涨停可能还行，但如果你在因子计算里用了收益率序列，连续的0收益涨停日会让很多统计指标失真。同理，长期停牌复牌后的第一个交易日，价格波动通常会巨大，如果复权因子在停牌期间发生了变动，复牌时的收益率会被错误放大。

我的处理方案是：给每根bar打一个limit_status标记（涨停/跌停/正常），停牌日单独标记；计算因子时，对于limit_status == 'limit_up'或'limit_down'的bar，收益率采用“市场微观结构调整”后的值，或者直接在相关统计中排除这类样本，避免假信号进入策略。

7.3 链式赋值：SettingWithCopyWarning不是小事

很多人在数据处理时会中招：

python复制sub = df[df['ts_code'] == '600000.XSHG']
sub['ret'] = sub['close'].pct_change()  # 会修改sub这个“视图”，但不一定改到原df

这行代码在某些pandas版本里，会在sub上做链式赋值，可能触发SettingWithCopyWarning，也可能不触发但实际没写回原数据，导致后面发现ret列不存在或全为NaN。

正确做法是先copy()再操作：

python复制sub = df[df['ts_code'] == '600000.XSHG'].copy()
sub['ret'] = sub['close'].pct_change()

或者用.loc显式定位后再赋值：

python复制df.loc[df['ts_code'] == '600000.XSHG', 'ret'] = df.loc[df['ts_code'] == '600000.XSHG', 'close'].pct_change()

如果你已经在用pandas 2.x，直接开启pd.options.mode.copy_on_write = True，链式赋值的问题会大幅减少，但为了可读性，我还是习惯显式copy()。

7.4 多标的拼接的合表操作

把多只股票的清洗结果合并成一个面板，很多人第一反应是concat，但这里有个性能陷阱：如果用concat循环追加几千次，速度极慢。正确做法是把所有股票的数据存在一个列表里，最后一次性concat：

python复制dfs = []
for code in stock_list:
    single = process_one_stock(code)
    dfs.append(single)
panel = pd.concat(dfs, ignore_index=True)

另外，如果你要把不同时间频率的数据合在一起，比如日线数据和财报数据、或者行情数据和资金流数据，merge_asof是一个特别好用的函数，它能按时间最近原则对齐数据，避免因为微小时间差导致的数据错位：

python复制daily = daily.sort_values('datetime')
fund = fund.sort_values('datetime')
merged = pd.merge_asof(daily, fund, on='datetime', by='ts_code', direction='backward')

direction='backward'的意思是，每一根日线bar，取之前最近一次已知资金流数据。这在处理“异步发布的数据”时特别有用。

7.5 数据版本与结果校验的“快照”习惯

最后分享一个让我少走弯路的好习惯：每次跑完清洗流水线后，把关键统计量打印出来并保存为快照。

python复制summary = df.groupby('ts_code').agg(
    start_date=('trade_date', 'min'),
    end_date=('trade_date', 'max'),
    bar_count=('close', 'count'),
    mean_close=('close', 'mean'),
    last_close=('close', 'last')
)
summary.to_csv('snapshot_daily_v1.csv')

下次重新处理后，直接对比snapshot，能快速发现哪些股票的数据时间范围变了、哪些股票的均值和收盘价发生了异常跳变。尤其是数据源更新后，如果你不知道它改了什么，这个快照对比可以帮你第一时间发现问题。

做量化这两年多，我自己最深的体会是：好的策略需要好的数据，而好的数据不是靠运气得到的，是靠一条条扎实的清洗规则、一次次交叉验证、一个个版本记录堆出来的。Pandas不是万能的，但把Pandas用得足够熟练，至少能保证策略的信号不会被脏数据污染。希望这篇实战分享能帮你少踩几个坑。