Python批量处理Excel与CSV：合并、拆分与清洗实战

每天处理表格的时候，最烦的不是数据本身有多复杂，而是那种需要重复操作几百遍的机械劳动。手上有三百个Excel文件要合并成一个总表，几十个CSV要批量转成Excel，或者一份一万行的数据要按部门拆成几十个小文件——手动去干，光是打开、复制、粘贴就能耗掉整整半天，眼睛盯到发酸，还可能漏行错列。

用Python批量处理Excel和CSV文件，就是把这些重复劳动压缩成几分钟的事。你只要写一次脚本，之后每次丢给脚本一堆文件，它就老老实实给你跑完。这篇文档我会从一个实际使用者的角度，把环境搭建、核心思路、常用案例、踩坑记录一次讲清楚，适合每天跟表格打交道的运营、财务、数据分析师，也适合刚学Python、想找个能立刻上手的练手项目的同学。

我自己也是从手动复制粘贴时代熬过来的。最早用VBA处理过一段时间的Excel，后来发现文件多了VBA也开始力不从心——打开文件、等宏运行、频繁报错，折腾下来不比手动快多少。直到换成Python，才真正感觉像是从扳手换成了机械臂。下面这个完整方案，你照着抄就能用。

1. 为什么这件事值得用Python干

先说个很现实的问题：Excel和CSV文件几乎贯穿了我们所有的工作流。Excel胜在格式灵活、公式强大、能做可视化，CSV胜在轻量、通用、几乎所有系统和编程语言都能直接读写。但这两类文件的处理效率，恰恰卡在了“批量”这个环节上。

手动处理三五个文件，老实说，问题不大，打开、复制、粘贴，十分钟内肯定搞定。但文件数量一旦上到几十上百，手动操作就开始失控了。有一个我之前特别崩溃的场景：每个月要从不同的业务系统里导出几十份CSV，格式基本一致，但表头有小差异，数据行数还不一样。我需要把整理好的最终表发给领导，每次都要花一整个下午去挨个打开、检查、拼接。用Python之后，这个流程变成了一个命令的事，跑完还能自动发一封带附件的邮件出去。

VBA能不能干这件事？能。但VBA有两个比较大的问题：第一，它依赖Excel环境本身，Excel一卡，宏跟着卡；第二，它擅长操作Excel内部对象，处理CSV这类外部文件、或者做更复杂的数据清洗、匹配、计算时，代码会越写越绕。而Python生态里，pandas、openpyxl、csv这几个库组合起来，基本覆盖了我日常能遇到的所有表格处理需求，而且计算引擎更健壮，处理几十万行的数据也不会把内存吃满后直接卡死。

还有一个很多人容易忽略的点：Python脚本可以脱离Excel环境独立运行。比如在服务器上定时跑脚本去拉数据、处理CSV，完全不依赖桌面端Excel是否打开。这一点在真正做自动化时太重要了，相当于把数据处理从“人肉操作”变成了“无人值守的流水线”。

我列个表格对比一下三种方案的体验：

这不是说VBA一无是处，那么简单粗暴的结论没意义。如果你只处理单个Excel文件、且重度依赖Excel本身的公式和图表，VBA仍然是个合理选择。但一旦场景进入“批量”和“多个文件联动”，Python的工程化优势就很明显了。

2. 环境准备与工具选型，先搭好地基再干活

很多人在开始前就倒在安装这一步了，尤其是第一次接触Python的朋友，看到官网那一堆版本号，不知道选哪个，装完又发现命令窗口里敲python没反应。这个环节我拆细一点讲。

2.1 Python本身的安装，记住两个关键点

第一点，去Python官网（python.org）下载，别从乱七八糟的下载站拿安装包，安全性没保证。选版本时优先挑最新的稳定版，不用刻意追特殊版本。第二点，Windows安装时，第一个界面上务必勾选“Add Python to PATH”这个复选框——这个决定了后面能不能直接在命令行里敲python调用，很多人装完就跑不了，八成是这一步漏了。

装好之后，打开命令行（Windows下用Win+R输入cmd回车），敲一行验证命令：

python --version

能显示版本号就说明基础环境OK了。如果报错“python不是内部或外部命令”，别慌，大概率是PATH没配置好，把Python的安装目录手动加进系统环境变量就能解决，网上搜“Windows添加PATH环境变量”照着做一遍即可。Linux或者macOS系统则一般自带Python 3，直接用python3命令调用就行。

2.2 安装核心库，一行代码的事

从Python官方的包管理工具pip来装。我在实际项目中用得最多的三个库是：

• pandas：处理结构化表格数据的核心，读写Excel和CSV都靠它
• openpyxl：pandas读写Excel时依赖的底层引擎，负责解析xlsx文件格式
• xlrd：主要用于读取旧版xls文件（比较少见，按需装）

安装命令如下：

pip install pandas openpyxl xlrd

国内网络环境下，如果pip下载速度慢到令人崩溃，可以加上国内镜像源参数：

pip install pandas openpyxl xlrd -i https://pypi.tuna.tsinghua.edu.cn/simple

顺便提醒一句，pandas安装时会自动带上numpy这个数值计算核心库，所以不用单独再装一次numpy。有些人会在网上找numpy的安装教程，其实装pandas就顺带解决了。

2.3 为什么用pandas而不是直接用openpyxl

这是个绕不开的选型问题。openpyxl很底层，它能让你精确控制Excel单元格的填充、字体、合并、边框这些“样式”，但它不擅长做“数据操作”——比如把100个文件读进来、过滤掉空行、按某列求和、再输出成一个新文件，用openpyxl逐行逐单元格操作又慢又绕。

而pandas把Excel和CSV当作一张二维数据表来处理，它的核心概念是DataFrame——你可以把它理解为内存里的一张可编程的表格。读文件、切片、过滤、分组、汇总、合并，全都有现成的函数，效率高，代码短，可读性强。

选型的完整结论是这样的：需要批量做数据整理、合并、筛选、统计，用pandas；需要精确控制Excel的单元格样式、插入图表、生成复杂格式的报表，才考虑用openpyxl直接操作。大多数批处理场景，pandas一个库就够用了。openpyxl更像是pandas的“幕后配角”，你装它只是为了给pandas提供Excel的读写引擎，平时自己很少直接碰它。

3. 三个核心场景，先想清楚再动手

批量处理这个事，说穿了就是反复执行同一个动作，但不同场景下的“同一个动作”差别非常大。我总结下来，日常遇到的需求基本逃不出下面三类。动手写代码之前，建议先想清楚你属于哪一类，因为不同场景的代码结构差异很大。

3.1 场景一：批量合并——把多个文件合成一个

这是最普遍的需求。比如把12个月的销售明细合并成全年的总表，或者把多个渠道的下载数据合成一份综合报表。这类需求的核心思路是：把所有文件逐一读取，放进同一个DataFrame，最后一次性写出去。

逻辑上很简单，但有两个坑我在实际中踩过。

第一个坑是表头不一致。有的文件前两行是标题和说明文字，第三行才是真正的表头；有的文件表头列名完全不一样。直接合并会变成“列错位”，数据全乱。所以合并之前要先检查每个文件的实际结构——我一般习惯先读取第一个文件看几行数据，确认表头和列顺序，再决定后面怎么统一处理，必要时给每个文件指定不同的表头行号。

第二个坑是重复表头混入数据。如果DataFrame里保留了一些说明性行，合并后总表里就会多出几行莫名其妙的文字。处理办法通常是读取后先按列名过滤一遍，比如“A列不能等于表头本身的文字”，或者用skiprows参数跳过不需要的行。

3.2 场景二：批量拆分——把一个文件分拆成多个

拆分需求的典型代表：一份全国门店的销售数据，想按城市拆成几十个文件发给各区域负责人；或者一份订单明细，想按日期维度把每天的数据单独存档。这类需求的核心思路刚好是合并的逆过程——先按某个字段（分组字段）把数据分离，然后循环输出。

拆分时最常用的分组字段是“城市”“部门”“日期”“客户ID”这种取值有意义的列。用pandas的groupby函数，一行代码就能得到多个分组。这里我建议拆分后的文件名尽量包含分组字段的值，比如“订单数据_20240501.csv”，这样一眼就能看出文件对应的内容，后面归档、查找都方便。

3.3 场景三：批量转换与清洗——格式转换和内容整理

第三类需求其实覆盖面最广，包括CSV转Excel、Excel转CSV、删除空行、替换错误值、筛选符合条件的数据、给数据加一列UUID、做标准化计算等。这类需求的特征是：文件数量可能不多，但每个文件内部的“脏乱差”需要统一治理。

经典的例子比较有代表性。比如从老系统导出的CSV文件，很多字段是空值，有的列里还有类似“未知”“#NULL”这样的垃圾占位内容。手动清理不现实，写脚本一次性清洗所有文件就太香了。另外一个高频应用是批量把旧的xls格式转成xlsx格式——某个Excel版本太老的系统只认新格式，几百个文件一个个另存转换能让人怀疑人生，脚本就三行代码的事。

这三个场景彼此不互斥，实际需求常常是合并+清洗同时做、拆分前先过滤一些行。我的建议是不要一上来就写完整脚本，先用小样本（比如两三个文件）验证流程，代码稳定了再全量跑，可以少踩很多坑。

4. 五个拿来就能用的实操案例

这一部分我直接给你抄作业级别的代码，每个案例都是我在真实工作中改过、跑过、调整过才稳定下来的版本。注意代码里的注释，那是我留下的处理细节。

4.1 案例一：批量合并多个Excel文件

假设你的文件夹结构如下：

D:/data/ ├── 1月.xlsx ├── 2月.xlsx ├── 3月.xlsx └── ...

每个文件里都是同一个结构的两列表格，列名为“姓名”和“销售额”。合并脚本如下：

import pandas as pd import glob # 获取所有Excel文件路径 file_list = glob.glob('D:/data/*.xlsx') df_list = [] for file in file_list: # 读取每个文件，假设表头在第0行 df = pd.read_excel(file, header=0) df_list.append(df) # 纵向合并所有数据 result = pd.concat(df_list, ignore_index=True) result.to_excel('D:/data/全年汇总.xlsx', index=False) print('合并完成，共', len(result), '行')

读这段代码的时候注意几个细节：glob模块负责用通配符匹配文件路径，这个比手动列文件名清单稳健得多，以后新增文件只要放进文件夹就会被自动扫到；pd.concat是pandas里的核心合并函数，纵向拼接时设置ignore_index=True，意思是不保留原来各自的索引，重新从0编号，否则最终表里全是从0开始的乱套编号，输出Excel时容易带上莫名其妙的行号列。

表格格式统一的话，这个脚本基本零修改就能用。如果有的文件头结构不同，先把不同文件单独处理。我在代码里加了print行数就是方便你确认“这个文件读到了多少行”，别小看这一步，常见问题之一是某个文件读取时格式异常，总体数据对不上，日志配合print可以第一时间定位到出问题的文件。

4.2 案例二：批量把一个CSV文件拆分成多个文件

按“城市”字段拆分：

import pandas as pd df = pd.read_csv('D:/data/全国订单.csv', encoding='utf-8-sig') for city, group in df.groupby('城市'): # 用城市名生成文件 group.to_csv(f'D:/data/订单_{city}.csv', index=False, encoding='utf-8-sig') print(f'{city}: {len(group)}行')

这里有一个编码细节是新手踩坑重灾区：输出CSV文件时用了encoding='utf-8-sig'而不是默认的utf-8。为什么不直接用utf-8？因为Windows下Excel打开不带BOM标记（即utf-8-sig）的CSV文件时，中文列名很容易变成乱码。utf-8-sig会在文件头部写入一个不可见标记，Excel用它来正确地识别UTF-8编码，这是我在被乱码折磨了若干次之后彻底学乖的经验。

输入文件如果读取时也乱码，可以尝试改成encoding='gbk'，尤其是从某些老系统导出的CSV文件，gbk编码很常见。拿不准编码时，一个笨办法是用记事本打开文件，另存为时看编码下拉框，通常能看出点名堂来。

如果是超大文件，比如几个GB的CSV，一次性全部read_csv进内存容易把电脑卡死。这时候可以分块处理：

import pandas as pd chunk_size = 100000 # 每10万行处理一次 for chunk in pd.read_csv('D:/data/超大文件.csv', chunksize=chunk_size): # 对每个chunk执行清洗或转换，再追加保存 ...

这个更实用，尤其当你处理的是日志导出或交易流水这类体积级别很大的文件时。

4.3 案例三：在Excel数据中查找特定字符串并提取匹配行

热词里提到“python查找excel中字符串”，这就是一个很典型的场景。比如老板让你从一个项目台账里把包含“服务器”关键词的所有项目摘出来，数据有两三万行，手动筛选也能做，但保存成独立文件还得再来几步。脚本如下：

import pandas as pd df = pd.read_excel('D:/data/项目台账.xlsx') # 在‘项目名称’列中查找包含‘服务器’的行 matched = df[df['项目名称'].str.contains('服务器', na=False)] matched.to_excel('D:/data/项目_筛选_服务器.xlsx', index=False) print(f'匹配到 {len(matched)} 行')

需要注意的地方是na=False这个参数。Excel里经常有空值，字符串匹配遇到空值NaN会直接报错或者得到False，加上na=False意思就是“空值当作不匹配处理”，这样脚本不会因为某个单元格为空而中断，也不会把空行误选进结果。

如果需要同时匹配多个关键词，用正则表达式：

matched = df[df['项目名称'].str.contains('服务器|数据库|机房', na=False)]

正则表达式里的竖线表示“或”，一条规则覆盖多个词，效率比一个个词去筛选高多了。我要强调一下，先在这个选项上留个心眼：字符串筛选前最好统一列的数据类型，有时候Excel列里混入了全角空格或不可见字符，str.contains可能匹配不上，可以先批量df['项目名称'] = df['项目名称'].astype(str).str.strip()清洗一下，再去做筛选。

4.4 案例四：批量给Excel加一列UUID

这种需求我在做数据系统对接时遇到过几次，业务方要求每条记录都有唯一标识（UUID），方便后续去重和关联。手动一个一个按F9刷新UUID，不现实。用脚本批量生成并写入：

import pandas as pd import uuid df = pd.read_excel('D:/data/客户数据.xlsx') # 生成UUID并转成字符串 df['UUID'] = [str(uuid.uuid4()) for _ in range(len(df))] df.to_excel('D:/data/客户数据_带UUID.xlsx', index=False)

UUID的好处在于它的唯一性几乎不依赖中心化发号器，分布式场景下也能放心用。这里用的uuid.uuid4()是随机版本，生成出的字符串长这样：f47ac10b-58cc-4372-a567-0e02b2c3d479。

如果你需要更短的可读的唯一编码，也可以用时间戳加序号组合，比如：

df['唯一编码'] = [f'D{ i:06d}-{int(__import__("time").time()*1000)}' for i in range(len(df))]

但这种方案取决于你是否接受时间戳的编码结构，按需选用即可。反正记住一点，能用稳定标准库生成唯一标识，就别自己拍脑袋写加密函数，维护起来容易出BUG。

4.5 案例五：批量做z-score标准化

热词里涉及“excel做z-score标准化”，这是数据处理里的基础操作。数据标准化就是为了让不同量纲的数据可以放在一起比较，典型应用是机器学习建模之前的数据预处理，以及制作多维度的评分看板。公式不复杂：

z = (x - mean) / std

用pandas手写这个公式也很方便：

import pandas as pd df = pd.read_excel('D:/data/各城市业绩.xlsx') # 对‘销售额’列做Z-score标准化 df['销售额_zscore'] = (df['销售额'] - df['销售额'].mean()) / df['销售额'].std() df.to_excel('D:/data/各城市业绩_标准化.xlsx', index=False)

这里要格外提醒一个细节：std()函数在pandas里的默认分母是n-1（样本标准差），而不是n（总体标准差）。如果你的口径必须和Excel表格里的某个公式完全一致，先确认对方用的是哪个版本。大多数人一般使用样本标准差，大哥不多。但如果对不上，pandas的std()可以传ddof=0参数改成总体标准差：

df['销售额_zscore'] = (df['销售额'] - df['销售额'].mean()) / df['销售额'].std(ddof=0)

这个细节容易让结果有微小误差，做报表时数字对不上，多半是出在这种口径差异上。

4.6 附带一个小场景：Excel与CSV互转

这个需求其实可以用更轻量的方式实现，单独跑一下：

import pandas as pd # 批量转CSV为Excel import glob for file in glob.glob('D:/data/*.csv'): df = pd.read_csv(file, encoding='utf-8-sig') out = file.replace('.csv', '.xlsx') df.to_excel(out, index=False) print(f'{file} -> {out}')

文件的编码和格式转换在批量场景下是最值得自动化的，因为手动做又枯燥又容易漏文件。

5. 高频问题排查与性能调优

写脚本是五分钟的事，跑脚本遇到问题、定位问题才是老手的真正分水岭。下面我把这些年踩过的坑集中放出来，按频率从高到低排列。

5.1 文件读取失败的三大元凶

文件已被占用：Excel文件如果正开着，Windows下Python去读取时经常报权限错误。这不是你代码的问题，是Excel打开文件时对文件加了独占锁。处理办法：先让所有相关Excel窗口关闭，再运行脚本。如果你在脚本里尝试写回同一个文件，遇到这个情况更常见，请养成“输出另存一个新文件”的习惯。

加载项导致的权限或安全限制：如果你处理的是别人传来的Excel文件，文件可能包含旧的加载项或宏，Excel打开时可能弹“加载项被禁用”之类的提示。Python读取这类文件一般不影响，但如果你用openpyxl保存后，加载项的元信息可能被清理，对方收到文件后会发现宏或某些功能没掉。这个不算BUG，是格式兼容层面的问题，交给对方前提前说明一下比较省事。

文件损坏或格式伪装：有的所谓Excel文件其实是用其它工具生成的非标准格式文件，把扩展名改成.xlsx骗过了人眼，但骗不过解析库。遇到读不了的情况，先试着手动用Excel打开，如果Excel也打不开，说明文件本身就坏了；如果Excel能打开但Python读不了，考虑用pd.read_excel(file, engine='openpyxl')强制指定引擎试试。

5.2 编码问题大全与终极解决办法

CSV文件读取乱码，最常见的是编码不匹配。我总结了一个排查线路：

Excel打开CSV不乱码，但Python读出来乱码 -> 文件大概率是GBK编码，读取时加encoding='gbk' pandas读出中文正常，但保存成CSV后Excel打开乱码 -> 保存时用encoding='utf-8-sig' Python读UTF-8编码文件时直接报错UnicodeDecodeError -> 文件可能是GBK或其它编码，尝试gbk或errors='ignore'

如果编码来回试都试不出来（这种情况一般出现在老系统导出文件），可以用codecs模块做兜底处理，或者用errors='replace'把无法解码的字符替换成占位符。但在生产环境里，编码问题务必搞清楚源头，我见过有人用errors='ignore'静默丢了一堆中文数据自己都不知道，后来做数据核对面目全非，代价很大。

5.3 数字变成科学计数法或丢失精度

这可能是Excel数据处理里最经典的坑了，尤其是身份证号、银行账号这类长度超过15位的字段，读取后容易被转成科学计数法，导致末尾几位变成0，数据直接损坏。

pandas读取时用dtype参数直接指定列类型：

df = pd.read_excel('D:/data/账号表.xlsx', dtype={'身份证号': str})

强制把该列当字符串读取，就不会触发数值转换。读CSV时也是同一个参数：

df = pd.read_csv('D:/data/账号表.csv', dtype={'身份证号': str}, encoding='utf-8-sig')

这个看似微小的设置，在数据保全层面极其关键。我吃过一次大亏，几千条身份证号被科学计数法毁了末尾两位，挽回成本极高。从那以后，只要是包含长数字文本的列，一律显式指定dtype=str，不做任何侥幸。

5.4 性能优化心得：大文件怎么跑得更快

处理几十万行的数据时，pandas本身的性能已经够用，通常瓶颈不在于计算，而在于文件的读写。几个我实测有效的优化手段：

• 读取CSV时，如果文件没有特殊字符，加上engine='c'参数（pandas默认c引擎，不必刻意写），处理速度远快于python引擎。
• 读取CSV时，如果不是所有列都需要，用usecols只筛选需要的列，减少内存占用。
• 大Excel文件的读取速度天然比CSV慢不少，因为要解析xlsx内部的XML结构，如果条件允许，优先考虑把Excel转成CSV流程再大批量处理，速度能提升一个量级。
• 写入数据时，指定index=False可以避免把多余的索引列写进文件，输出文件更干净，体积也更小。

5.5 批处理时脚本中途崩了怎么办

很多人都遇到过脚本跑了一半报错，前面的文件处理好了，后面的还没处理。重跑一遍吧，已经生成的重复文件还得清理，不重跑吧，又怕漏掉。我的做法是在循环里加日志和断点续跑的思路：

import os import pandas as pd import glob processed_dir = 'D:/data/done' os.makedirs(processed_dir, exist_ok=True) for file in glob.glob('D:/data/*.xlsx'): # 如果已经处理过，跳过（实现断点续跑） done_marker = os.path.join(processed_dir, os.path.basename(file) + '.done') if os.path.exists(done_marker): continue try: df = pd.read_excel(file) # 中间处理逻辑... df.to_excel(file.replace('.xlsx', '_cleaned.xlsx'), index=False) # 打一个完成标记 open(done_marker, 'w').close() except Exception as e: print(f'{file} 处理失败: {e}')

这个思路的核心是“打标记”：处理成功的文件生成一个对应的.done标记文件，下次运行时跳过这些，只处理未完成的文件，实现自动断点续跑、重复执行也不会产生垃圾数据。这个经验在文件数量特别大的场景下非常实用，我强烈建议工程化脚本时保留这个习惯。

6. 从一次性脚本到日常工具，还差这几步

脚本写多了，你会发现“能跑”和“好用”之间隔着一整个田野。平时自己偶尔跑一次，代码写得随便点无所谓。但如果你跟我一样，逐渐走上了用Python处理表格的老路，总有一天你会发现：同事开始问你要脚本、老板希望你把这套东西做成能重复使用的工具——这时候就需要做一些工程化改造了。

6.1 把处理逻辑抽象成函数

永远不要把自己的代码写成一大串从头到底的线性脚本。今天处理12个月的数据，改了三个月的文件，明天要处理另一个业务线的文件，发现脚本里写死了文件名和图表的目录，改起来头大。把核心逻辑包成函数，以后换数据源只需要换参数：

def merge_excel_files(input_dir: str, output_path: str, header_row: int = 0): """合并一个目录下所有Excel文件""" import pandas as pd import glob df_list = [] for file in glob.glob(f'{input_dir}/*.xlsx'): df = pd.read_excel(file, header=header_row) df_list.append(df) result = pd.concat(df_list, ignore_index=True) result.to_excel(output_path, index=False) return len(result)

这个函数签名里可以看到两个可调参数：输入目录、输出路径。这样改表头行号只需header_row=2，而不用去代码堆里挖变量。

6.2 给脚本加上日志和异常捕获

print虽然好用，但真正跑起来还是要保留一份能定位问题的方式。直接用日志记录比print可靠得多：

import logging logging.basicConfig( filename='D:/data/processing.log', level=logging.INFO, format='%(asctime)s - %(levelname)s - %(message)s' ) logging.info('开始处理文件') try: df = pd.read_excel('D:/data/example.xlsx') logging.info(f'读取成功，共{ len(df)}行') except Exception as e: logging.error(f'读取失败: {e}', exc_info=True)

日志文件把每次运行过程和错误堆栈留下来，出了问题时不用靠用户回忆“刚才报了什么错”，直接去翻日志就行。

6.3 把脚本打包成exe，让自己的工具能交给别人用

这是让脚本“去程序员化”的关键一步。同事不一定装了Python，直接把脚本丢给他们等于没传。用PyInstaller可以把.py文件打包成exe，对方双击就能运行：

pip install pyinstaller pyinstaller -F merge_excel.py

打包完后在dist目录下会生成一个merge_excel.exe，把exe和数据文件放到同一目录，同事拿来就能用。不过要注意：打包出来的exe体积比较大（因为带上了Python解释器和相关库），属正常现象；另外杀毒软件偶尔会对打包出的exe误报，建议用--onefile --clean参数重新打包试试，或者添加白名单。

我自己的习惯是：脚本写好先试运行，确认无误后，再精致地图解一遍参数，最后打包。这个流程下来，同事用脚本的时候基本不需要我的协助，有什么问题看日志也能自己反馈清楚。

6.4 少数几个不该用Python的场景

诚实的博主必须说清楚：Python不是万能的。以下这些场景你可以先停下脚本，想一想是不是真的有必要：

• 只有三五个文件，且只需要简单操作时，手动处理更快，没必要为这点规模写个脚本。
• 需要大量保留Excel原始格式（颜色、公式、图表、条件格式）时，pandas读写会简化掉很大一部分样式，取而代之的是数据本身，务必确认对方能接受。
• 依赖多个Excel工作表之间的公式联动，且公式必须动态更新，这时候保持Excel原格式或许是更好的方案，Python写入公式会复杂得多，而且公式调试也不直观。

搞清楚什么该自动化、什么不该自动化，比会写脚本更重要。我的经验准则是：重复两次以上的操作才值得写脚本，涉及敏感数据的操作更要谨慎校验。

还有一个小经验，关于日常使用的工具组合。很多人在热词“markdown表格转换excel”、“csv文件分割神器2.0”这些工具之间反复横跳，找我推荐“最好用的”。我的建议是：别人家的工具可以有，但能沉淀成自己脚本核心逻辑的场景，一定要留一手脚本，因为你的数据格式、你的业务逻辑、你的输出要求永远是独特的，通用工具往往只覆盖80%的情况，剩下20%需要你动手补充。学会用Python批量处理Excel和CSV之后，你会发现这个“剩余20%”才是你真正拉开工作效率差距的地方。