cumprod()是Pandas中实现列内逐行累乘的最直接高效方法，默认axis=0按列计算，自动处理NaN（首非空值起累乘），需警惕dtype、axis误设及跨chunk衔接问题。
直接用 cumprod()，别绕弯
想对一列数字做“从上到下逐个累乘”，cumprod() 就是 Pandas 里最直白的解法。它不依赖循环、不手动维护中间变量，底层用的是优化过的 NumPy 累积运算，速度和可读性都在线。
常见错误是试图用 apply() + 自定义函数模拟累乘，或者误用 prod()（那是整个 Series 求一次总积，不是累积）。
-
cumprod()默认按行方向（axis=0）计算，适合单列或 DataFrame 各列独立累乘 - 遇到
NaN时，首个非空值之前全为NaN，之后从该值开始累乘（符合多数业务预期） - 若数据含
0，后续所有结果都会是0——这不是 bug，是数学事实，但容易被忽略导致误判异常
DataFrame 多列分别累乘要指定 axis=0
对 DataFrame 调用 cumprod() 时，默认就是按行索引方向累乘（即每列各自独立算），不需要额外参数。但很多人会下意识加 axis=1，结果变成“每行内各列相乘再累积”，完全偏离需求。
比如有两列 ['a', 'b']，你想要 a 列自己累乘、b 列自己累乘，就直接 df.cumprod()；如果写了 df.cumprod(axis=1)，就会把每行的 a 和 b 先乘起来，再对这个乘积序列做累积——逻辑完全不同。
立即学习“Python免费学习笔记（深入）”；
- 确认目标：是“列内累积”还是“行内先合并再累积”？绝大多数场景是前者
- 检查结果形状：累乘后 DataFrame 行数不变、列数不变，说明正确；若列数变少或出现意外
NaN，大概率是 axis 设错了 - 数值类型影响：如果某列是整型但累乘结果溢出（如 uint8 跑到 256），Pandas 会自动转成 int64，但中间过程可能静默截断，建议提前用
astype(float)避坑
处理起始 NaN 或空值时行为要心里有数
cumprod() 对 NaN 的处理很固定：遇到第一个非空值才开始计算，此前位置全为 NaN。这和 fillna().cumprod() 完全不同——后者会用填充值参与运算，彻底改变结果。
典型陷阱是看到开头几行结果是 NaN，就急着 fillna(1)，结果让本该跳过的缺失段落变成了“×1”，后续所有值都被污染。
- 想跳过开头缺失、从首个有效值启动累乘？保持原样，这是默认行为，不用干预
- 想用某个值（如 1）替代缺失再累乘？明确写
df.fillna(1).cumprod()，但得清楚这改变了原始语义 - 时间序列中，若首条记录就是
NaN，cumprod()返回仍是NaN，不会“自动取下一个非空值补位”——这点和ffill()逻辑无关
性能敏感时注意 dtype 和 chunking
对百万级数据调用 cumprod() 很快，但前提是 dtype 合理。如果一列是 object 类型（比如混了字符串或 None），Pandas 会退化成 Python 循环，速度暴跌 10 倍以上，且可能直接报 TypeError: unsupported operand type(s) for *: 'str' and 'float'。
另一个隐蔽问题是：在分块读取大文件（如 pd.read_csv(..., chunksize=...)）后对每个 chunk 单独调用 cumprod()，会导致每个 chunk 内部重置累乘起点——这不是函数问题，而是你没把上下文连起来。
- 执行前先检查
df['col'].dtype，强制转成float64或int64再算 - 需要跨 chunk 累乘？得手动保存上一块的末尾值，作为下一块的初始乘子，
cumprod()本身不支持“接续”模式 - 极大数据量下，考虑用
dask.dataframe替代，它的cumprod()支持延迟计算和分区衔接
