1. 需求场景拆解什么情况下非要把 Excel 切开1.1 四种高频切分场景看看你中了几个Excel 按行切分这件事听着像小需求但只要你在数据岗待过一段时间就会发现它几乎是每个月底的固定动作。我把过去几年遇到过的情况归了归类大致跑不出下面四种。第一种是导入限制触发的被动切分。不少业务系统的导入模板对单文件行数有硬性限制超过就直接报错或者静默截断一半数据那种导进去了但少了一半最要命因为不看回执根本发现不了。这时就必须把一张几十万行的明细拆成若干个小文件一个个喂进去。第二种是分发需求导致的切分。比如一张全量客户对账单需要按区域或者按负责的销售拆成多个文件分别发给不同的人。全量发出去既没意义也不安全每个人只看自己那一块就行。这种切分的依据不是行数而是某个字段的取值。第三种是性能问题倒逼的切分。一个两三百万行的表打开要等半分钟随便筛一下又卡住公式一多直接假死。这时候与其硬扛不如按时间或者按业务编号切成若干张单表控制在十万行以内操作体验立刻回来。第四种是送审送检的格式要求。某些流程要求提交的文件每份不得超过固定大小或者每份只能包含固定条数的记录一条不多一条不少。这种对切得准的要求最高多一行少一行都要返工。这四种场景看起来都是把大文件变小文件但切分的依据、对格式的要求、出错后的代价完全不同。想清楚自己属于哪一类后面的方案选型才不会走弯路。1.2 手工切分的成本账为什么必须工具化有人会想不就是复制粘贴吗插几行空行分一分不就完了。我算过一次账结论是这条路基本走不通。假设一个 12 万行的表要按每 5000 行切一份共 24 份。手工流程是定位到第 5001 行、选中剩余所有内容、剪切、新建工作簿、粘贴、另存为、命名、关掉。熟练的人一份大概 40 秒24 份接近 20 分钟。这还不是最糟的最糟的是中途被打断回来忘了切到第几行了只能从头核对。更要命的是准确性。手工操作里最容易出的事故是剪切时的选区偏移导致某一行重复出现在两个文件里或者某一行直接消失。12 万行的数据少一行多一行肉眼根本看不出来等到下游对不上账才发现回溯成本远高于当初写个脚本的时间。还有一次性的问题这个月切完了下个月数据一更新全部重来。所以我的判断很简单——只要这个动作发生第二次就值得写成工具。第一次可以手工验证逻辑对不对第二次开始一律跑脚本。写脚本的投入大概是一两个小时换来的是每次几十秒出结果而且结果稳定可复现。这笔账怎么算都划算。1.3 切分粒度怎么定行数、大小还是业务键定了要工具化下一个问题就是按什么标准切。这个决策直接决定了工具的设计选错了后面怎么调都别扭。按固定行数切是最通用的一种每 N 行一个文件不管内容是什么。它适合纯导入场景因为下游只关心每个文件不超过多少行。N 的取值一般看下游限制留 10% 到 20% 的余量比较稳妥比如限制 5000 行就按 4500 切。按文件大小切更适合走传输渠道的场景。行数和大小不是线性关系一行全是长文本和一行全是数字体积能差十几倍。如果你的约束是每个文件不超过 5MB那就得按字节算边写边累加体积超过阈值就换下一个文件。按业务键分组切是另一套逻辑常见的是按日期、按区域、按部门。这种切法的特点是每份文件的大小完全不可控——热门区域的记录可能是冷门区域的几十倍。所以实践中通常是两级策略先按业务键分组组内再按行数二次切分组太大就继续拆组太小可以考虑合并。我个人的默认配置是数据类文件按行数切分发类文件按业务键切交付类文件两者结合。这个默认值覆盖了大概八成的情况剩下的两成再单独调。2. 方案选型三条路线各自的适用边界2.1 路线一办公软件内置功能与 Power Query先说不用写代码的路子因为很多人被要装 Python这一步劝退了。主流办公套件里部分版本确实内置了拆分工作表的功能一般藏在数据选项卡或者工具箱里。它的优点是零门槛点几下就出结果缺点是参数非常死通常只支持按固定行数或者按某列的不同取值没法做复杂逻辑比如跳过前三行标题、从第四行开始算、每份保留表头。而且不同版本的功能位置和命名还不一样换个环境就找不到了。更靠谱的无代码方案是Power Query。它的思路是把切分变成一次数据变换先给数据加一个索引列然后用索引除以每份行数取整得到一个分组号列再按这个分组号分组最后把每组导成一个独立的表或者文件。整个过程有记录、可复用数据更新了只要刷新一下。Power Query 的优势在于它是办公软件原生能力不需要额外环境同事接手也能看懂步骤。它的短板也很明显处理几十万行以上的数据时刷新速度会明显变慢而且导出成多个独立文件这一步原生界面支持得并不好通常还得配合一段简短的宏代码来实现批量另存。所以我的判断是数据量在十万行以内、逻辑简单、需要交付给非技术同事维护的优先 Power Query。超过这个量级或者逻辑里带条件判断的直接上脚本别在图形界面里绕。2.2 路线二脚本化处理openpyxl / pandas脚本路线是main力方案也是我实际工作中用得最多的。Python 生态里处理 Excel 最常用的两个库定位完全不同得分开说。pandas强在数据处理读进来就是一个二维表结构切片、筛选、分组都是一行代码的事。用它做切分核心代码可能就七八行。但它有个致命短板读写过程中格式基本全丢。字体、颜色、边框、列宽、条件格式、合并单元格统统保不住写出去的就是一张干干净净的裸表。如果你的表只是纯数据这反而正合适——快、简单、体积小。openpyxl强在文件结构层面能读到工作簿的每一个细节样式、公式、批注、超链接都能拿到。它支持流式读写模式处理大文件时内存占用控制得很好。代价是 API 相对啰嗦写个切分脚本大概要五六十行而且逐单元格复制样式会明显拖慢速度。我的实际组合是纯数据切分用 pandas需要保留格式的用 openpyxl。两条路都准备着遇到什么活用什么工具不用强行统一。2.3 三条路线的横向对比表把几种方案摆在一起对比选型的时候能少纠结。维度办公软件内置功能Power Querypandasopenpyxl上手门槛极低低中中是否需要额外环境否否是是十万行以内速度快较快很快快百万行级别基本不可用很慢内存吃紧流式模式可扛格式保留部分保留基本不保留不保留可完整保留复杂逻辑支持无中等强强可维护性差好好好批量输出多文件一般需配合宏好好表格里最值得注意的一行是百万行级别。很多人踩的坑是拿 pandas 硬读一个两百万行的表机器内存不够直接崩掉还以为是代码写错了。实际上 pandas 读 Excel 是先把整个文件解开成对象再转换峰值内存大概是文件体积的十几倍一个 50MB 的表就可能吃掉 800MB 以上内存。这种情况必须换 openpyxl 的只读流式模式它是一行一行吐数据内存占用基本恒定。3. 核心实现按行切分脚本的关键细节3.1 环境准备与库版本环境这块没什么玄机但版本对不上会浪费很多时间排查。python -m venv venv source venv/bin/activate # Windows 下用 venv\Scripts\activate pip install openpyxl pandas我一般会顺手把版本固定下来写进一个依赖文件里。原因是 openpyxl 在 3.x 的几个小版本之间只读模式对某些特殊文件的行为有过变化尤其是带大量合并单元格的表格老版本会直接抛异常。固定版本能保证今天能跑的脚本半年后同事拿去也能跑。pip freeze requirements.txt还有一个容易被忽略的点处理 Excel 的机器上不一定要装办公软件。openpyxl 是纯 Python 实现不依赖任何本地组件扔到服务器上照样跑。这点在做定时任务的时候特别有用——不用为了跑个切分脚本在服务器上装一整套办公套件。3.2 表头定位别只写 header1这一段是真实踩过的坑值得单独拎出来说。几乎所有教程里的切分示例都默认第一行是表头第 1 行开始是数据。但真实业务表格里第一行很可能是标题2024 年某季度销售明细表第二行是制表人和日期第三行才是真正的字段名第四行开始才是数据。你按第一行表头去切切出来的每个文件都带着一行大标题和一行日期导入下游系统百分百报错。所以我的做法是表头行数和数据起始行一律做成显式参数不猜。HEADER_ROWS 3 # 前 3 行作为表头每份文件都重复写入 DATA_START_ROW 4 # 从第 4 行开始算数据判断表头到哪一行为止有个很土但很有效的办法看第一列从哪一行开始往下都是同类型的东西。标题行第一列通常只有一个格子有内容后面全是空字段名那一行第一列是个短词数据行第一列是具体的编号或者名称。人工扫一眼就能定定完写死别在代码里做启发式猜测那玩意儿在边界情况下比人不可靠。还有一类表更阴险中间夹着小计行或者空行。这种表在切分前必须先清洗把所有非数据行剔掉否则切出来的分片里会混进小计行下游一算总和就翻倍。我的处理习惯是先跑一遍清洗把数据规整成首行字段名 纯数据的标准形态再进入切分流程。多一步但省心。3.3 主流程代码与逐段解释下面这份是按固定行数切分的完整实现用的是 openpyxl 的流式读写模式几十万行也不至于把内存吃爆。import os from openpyxl import load_workbook, Workbook def split_by_rows(src_path, out_dir, rows_per_file5000, header_rows1, sheet_nameNone, prefixNone): src_path 源文件路径 out_dir 输出目录 rows_per_file 每个分片包含的数据行数不含表头 header_rows 表头占用的行数每份分片都重复写入 sheet_name 指定工作表None 表示取第一个 prefix 输出文件名前缀None 表示用源文件名 os.makedirs(out_dir, exist_okTrue) base prefix or os.path.splitext(os.path.basename(src_path))[0] wb_in load_workbook(src_path, read_onlyTrue, data_onlyTrue) ws_in wb_in[sheet_name] if sheet_name else wb_in.worksheets[0] row_iter ws_in.iter_rows(values_onlyTrue) # 先把表头抓出来存着后面每份都要重写 headers [] for _ in range(header_rows): headers.append(list(next(row_iter))) part_no 1 buffer [] def flush(buf, idx): wb_out Workbook(write_onlyTrue) ws_out wb_out.create_sheet(title(ws_in.title or Sheet1)[:31]) for h in headers: ws_out.append(h) for r in buf: ws_out.append(list(r)) name f{base}_part{idx:03d}.xlsx path os.path.join(out_dir, name) wb_out.save(path) print(f[OK] {name} 数据行数 {len(buf)}) return path for row in row_iter: if row is None: continue # 全空行直接丢弃避免污染分片 if all(v is None or str(v).strip() for v in row): continue buffer.append(row) if len(buffer) rows_per_file: flush(buffer, part_no) part_no 1 buffer [] if buffer: flush(buffer, part_no) else: print([WARN] 没有剩余数据最后一片未生成) wb_in.close()逐段说一下为什么这么写。read_onlyTrue是性能关键。开着这个模式openpyxl 不会把整个工作表解析成对象树而是按行流式吐数据内存占用基本恒定。代价是这时候不能改单元格、不能读样式只能读值。切分场景恰好只需要值所以这个取舍完全划算。data_onlyTrue处理的是公式问题。很表里的关键列是公式算出来的不加这个参数读到的就是VLOOKUP(...)这串字符串写出去下游全是错的。加了之后读的是缓存值但有个前提条件这个文件必须曾经被办公软件打开并保存过。如果文件是程序直接生成的、从没被打开过缓存值压根不存在读出来是None。这个坑我栽过一次排查了大半天最后发现是上游系统导出时没计算公式。iter_rows(values_onlyTrue)省掉了单元格对象直接返回值的元组速度快不少。全空行过滤那几行别小看。真实表格里经常出现看着没数据但实际有格式的行或者中间的一段间隔行不过滤的话会被当成数据行数进去导致每份分片的实际有效行数少于预期。write_onlyTrue同样是流式写入配合ws.append()一行一行推。注意这个模式下不能读回刚写的内容也不能合并单元格所以样式相关的操作要提前想清楚。3.4 保留格式的进阶写法有些场景必须保格式比如带底色标记的异常记录、带边框的报表模板、带条件格式的看板。这时候write_only和values_only都得关掉改成逐单元格搬运。from openpyxl import load_workbook def copy_row_with_style(ws_in, ws_out, row_idx): for col_idx, cell in enumerate(ws_in[row_idx], start1): new_cell ws_out.cell(rowrow_idx, columncol_idx, valuecell.value) if cell.has_style: new_cell.font cell.font.copy() new_cell.fill cell.fill.copy() new_cell.border cell.border.copy() new_cell.alignment cell.alignment.copy() new_cell.number_format cell.number_format这段逻辑本身不复杂但性能代价非常大。样式复制要反复创建对象实测下来比纯值写入慢五到十倍。一个 20 万行、30 列的表纯值写入大概十几秒带样式搬运要两三分钟如果还有大量条件格式时间还得往上翻。我的做法是分级处理表头行一定要搬样式因为它是每份文件的脸面格式错了很显眼数据行只搬数字格式和填充色这两个下游最常校验字体和边框一律放弃。这样能省掉一大半时间效果上也能应付绝大多数场景。合并单元格要单独提醒一句。如果你的表头里有合并单元格比如基本信息横跨三列直接按原样逐格搬运会报错必须先读一次合并区域列表在新工作簿里重建同样的合并区域。这块代码稍微绕我一般建议能用取消合并 居中对齐伪装的就别用真合并省事很多。3.5 参数计算文件大小估算与分片数rows_per_file这个参数别拍脑袋定估一下更稳。Excel 单工作表的上限是 1048576 行、16384 列超过这个数保存都会失败。所以如果你的源表接近这个量级切分不是可选项而是必须项。文件体积的粗估可以用这个经验公式每 1 万行 × 每行 20 列的数据量xlsx 格式大约在 1.5MB 到 3MB 之间。变量主要来自单元格内容的平均长度和一列里长文本的比例。如果一列是备注字段、单格动辄上百字那体积会明显偏大。分片数就是总行数除以每片行数向上取整import math total_rows 123456 rows_per_file 5000 part_count math.ceil(total_rows / rows_per_file) print(part_count) # 25留余量的习惯我一直保持着。下游说限制 5000 行我就按 4500 切因为下游的计数口径可能和我不一样——它可能把表头也数成一行也可能把空行算进去。留 10% 的缓冲比自己反复调试省事得多。4. 实操记录一次20万行数据的完整切分过程4.1 前置检查清单正式跑之前我有一套固定的检查动作五分钟能做完但能挡掉大部分事故。第一确认总行数和有效行数。用办公软件打开拉到最底下看看再配合脚本读一遍计数两个数对不上就说明有隐藏行或者中间的空行干扰得先搞清楚。第二确认表头行数和字段数。数一下列数看看有没有隐藏列。隐藏列这事特别隐蔽肉眼看不见但在文件里是存在的切完之后突然多出来一列追查起来很费劲。第三检查有没有公式依赖跨表引用。如果某一列的值是靠引用另一个工作表算出来的切分时那个被引用的表没被带过去值就变成None或者#REF!。解决办法是切分前先把公式列转成值。第四确认输出目录有写权限而且要留足空间。20 万行的表切出 40 多个文件加起来体积可能比源文件还大每个文件都有自己的结构开销。第五定好命名规则并写下来。源文件名_part001.xlsx这种带三位序号的格式是我一直在用的好处是文件管理器里排序天然正确不会出现 part10 排在 part2 前面那种尴尬。这套检查我最初是凭记忆做的漏过两次之后老老实实写成了一张清单贴在显示器边上。清单化的好处是换台机器、换个人流程一样。4.2 执行与耗时实测那次的源文件是 203,847 行、26 列的订单明细体积 89MB包含日期、金额、编号、备注四类字段备注列平均长度在 40 字左右。参数定为rows_per_file5000、header_rows1理论上会切出 41 个文件最后一片只有 3847 行。实测耗时分布大概是这样阶段耗时说明打开文件并进入只读模式约 2 秒只解析结构不加载数据逐行读取并缓冲约 25 秒大头是解析 XML写入 41 个文件约 18 秒每片约 0.4 秒合计约 45 秒内存峰值约 180MB45 秒对比手工操作的两三个小时量级差异不用多说。内存峰值 180MB 也在可控范围内随便一台普通办公机都能扛。这里有个细节值得说整体耗时的大头在读不在写。因为是流式读取每读一行都要走一遍 XML 解析26 列就是 26 次取值。如果列数更多或者单元格内容更长这个时间还会涨。想提速的话最有效的办法是先把源文件转成 CSV 再处理CSV 的解析速度比 xlsx 快一个数量级处理完再转回 xlsx。当然这么做的前提是格式不重要。4.3 结果校验方法切完不校验等于没做这是我最坚持的一条。最简单的校验是行数求和。把 41 个分片的有效数据行数加起来必须等于源文件的有效数据行数。import os, glob from openpyxl import load_workbook total 0 for f in sorted(glob.glob(output/*.xlsx)): wb load_workbook(f, read_onlyTrue, data_onlyTrue) ws wb.worksheets[0] cnt sum(1 for _ in ws.iter_rows(min_row2, values_onlyTrue)) print(os.path.basename(f), cnt) total cnt wb.close() print(合计:, total)第二个校验是关键字段去重计数。挑一个理论上唯一的字段订单号、流水号之类把所有分片里的这个字段汇总起来去重去重后的数量应该和总行数一致。不一致就说明有重复行多半是切分时的边界处理有问题。第三个校验是抽样比对首尾。每个分片的第一行和最后一行拿回源文件核对一下看看是不是连续。这一步能抓出漏行和错位两类问题而且人工看几眼就能确认比写脚本快。三个校验都过我才认为这次切分是成功的。多花五分钟换来的是不用在下游报错时手忙脚乱。5. 踩坑手册数据不失真的十个细节5.1 数据失真类问题这一类最恶心因为文件能打开、能导入、不报错但数据本身已经悄悄变形了。长数字变科学计数法。订单号、银行卡号、身份证号这类 15 位以上的数字写出来经常变成1.23457E18。根子在类型判断上——写入时如果值是个数字类型Excel 会按数值处理并按列宽显示。解决办法是在写入前统一转成字符串并且在写完后把该列的数字格式设成文本。这个坑我在一个银行卡号字段上栽过几十万条数据全部报废只能重跑。前导零丢失。001234写进去变成1234看着是小问题但如果下游拿这个当主键匹配全崩。同样是文本格式的问题处理方式和上一条一样。日期变成一串数字。Excel 内部把日期存成序列号2024-01-01 实际是 45292。如果读的时候拿到的不是 datetime 对象而是个整数写出去就是 45292 这种鬼东西。openpyxl 一般能正确识别但如果单元格被设成了常规格式就识别不出来。稳妥的做法是读的时候判一下列名或者值范围必要时手动转换。超长文本被截断。Excel 单元格的字符上限是 32767 个超过就直接丢。注释类字段偶尔会撞上这个限制。切分前扫一遍最长的那几格心里有个数。5.2 结构丢失类问题合并单元格直接报错。前面提过write_only模式完全不支持合并普通模式下也得手动重建。撞上这个错误的典型表现是脚本跑到一半抛异常然后你发现源文件的表头长得像千层饼。条件格式全部失效。用 pandas 处理的话条件格式、数据验证、批注、超链接这四样东西一定全丢因为这个库压根不看这些信息。需要保留就得走 openpyxl 逐格搬运而且条件格式还得单独用formatting相关的 API 重建代码量不小。列宽变成默认值。这是个不影响功能但很影响观感的问题。切出来的文件每列都是标准宽度文字挤在一起或者留出大片空白。补救办法很简单写完之后遍历一遍所有列按内容长度的粗略估计设一下for col in ws_out.columns: max_len 0 letter col[0].column_letter for cell in col[:200]: # 只看前 200 行够用了 if cell.value is not None: max_len max(max_len, len(str(cell.value))) ws_out.column_dimensions[letter].width min(max(max_len * 1.2, 8), 50)打印区域和页眉页脚丢失。这个只有做正式报表交付时才会在意普通数据处理忽略即可。5.3 性能与稳定性问题内存爆掉。前面算过pandas 读 Excel 的峰值内存大概是文件体积的十几倍。一个 60MB 的表在 8GB 内存的机器上跑很容易触发换页慢得像死机。换 openpyxl 的流式模式能解决代价是代码长一点。max_row返回 None。只读模式下这个属性并不总是可靠如果文件生成时没写 dimension 信息或者被某些工具改过max_row可能返回一个错误的数甚至直接报错。所以分片数别用max_row算老老实实边读边计数。写入时文件被占用。如果输出目录里已经有一个同名文件被打开了哪怕只是预览窗格开着保存会抛权限错误。脚本里加个 try 捕获提示请关闭已打开的输出文件比抛一堆堆栈信息友好得多。磁盘空间不够。切分是一变多总体积通常会膨胀 10% 到 30%因为每个文件都有自己的结构头和共享字符串表。源文件 1GB输出目录至少留 1.5GB。5.4 常见问题速查表把上面这些整理成一张表出问题的时候按症状查比翻代码快。症状最可能的原因处理方向长数字变成科学计数法按数值写入转字符串 设文本格式前导零消失同上同上日期显示为整数单元格格式为常规显式转 datetime 或设日期格式分片里出现无关的小计行源表未清洗切分前先过滤非数据行公式列全是 None文件从未被办公软件打开保存先手工打开保存一次或让上游改导出方式脚本跑到一半报错表头有合并单元格关闭只读写入模式并重建合并区域处理速度极慢逐格读样式只保留必要样式其余放弃内存占用持续上涨用了普通读取模式改read_onlyTrue保存报权限错误输出文件被占用关闭预览窗格或已打开的文件每份分片少几行空行被当成数据计入增加全空行过滤6. 交付给别人用把它做成傻瓜工具6.1 参数化与配置文件脚本自己用怎么都好说一旦要交给同事参数就得从代码里搬出来。我一般把配置写成一个独立的文本文件或者命令行参数最少包含这几项源文件路径、输出目录、每片行数、表头行数、工作表名称。这样改需求的时候不用碰代码改一行配置就行。import argparse parser argparse.ArgumentParser(description按行切分 Excel) parser.add_argument(-i, --input, requiredTrue, help源文件路径) parser.add_argument(-o, --output, defaultoutput, help输出目录) parser.add_argument(-n, --rows, typeint, default5000, help每片数据行数) parser.add_argument(-h-row, --header-rows, typeint, default1, help表头行数) parser.add_argument(-s, --sheet, defaultNone, help工作表名称) args parser.parse_args()用起来就是一句命令python split_excel.py -i 源数据.xlsx -o 输出 -n 4500 -h-row 3比让同事去代码里找ROWS_PER_FILE 5000这一行改数字体验好太多了。再往上一步是做成可视化界面。用 Python 自带的图形库搭个简单的窗口选文件、填数字、点按钮二十分钟能写完。这一步的价值不在于技术含量而在于让不会用命令行的人也能自助操作。我做过一次之后同组同事再也不来问能不能帮我切一下了。6.2 日志与异常提示怎么写工具交付出去之后最花时间的不是写代码是回答为什么我这边报错了。所以日志和错误提示必须写得像人话。原则一打进度别打细节。每一片写完打一行已生成 xxx_part005.xlsx数据行数 4500跑一万行能出几行不多不少。别打每一行的日志几十万行输出刷屏真出问题反而找不到。原则二错误信息要带位置。与其打一个KeyError不如打读取失败指定工作表 明细 在文件中不存在当前文件包含的工作表有明细表、汇总、参数。第二句能直接让人自己解决第一句只能来找你。try: ws wb[sheet_name] except KeyError: names 、.join(wb.sheetnames) raise SystemExit(f未找到工作表 [{sheet_name}]当前文件包含{names})原则三结束给个总结。跑完了打一行共生成 41 个文件合计 203847 行输出目录xxx。这一行是用户唯一的确认信号没有它用户永远不确定是不是跑完了。最后是个经验把日志同时写进文件。窗口一关日志就没了出问题时用户根本说不清发生了什么。留一份run.log在输出目录里事后能复盘。6.3 使用说明文档的模板给非技术同事的工具一份一页纸的说明基本是必需品。我通常按这个结构写不用长但要能照着做。第一段写这个工具干什么把一个大 Excel 按指定行数拆成多个小文件每份都保留表头。一句话讲清楚不讲原理。第二段写怎么用用截图配三步双击启动、选文件、填数字点开始。每一步配一张图不写文字也能看懂。第三段写结果在哪明确说明输出文件在源文件同目录下的output文件夹里命名规则是什么样。第四段写常见情况列三到五条最可能遇到的文件正被打开会失败、表头行数填错了怎么办、处理大文件需要等一会儿别重复点击。第五段写找谁。留个联系方式别留一堆技术细节用户不需要。这份说明我自己看过好几遍越写越短。最初写了三页后来发现没人看压到一页之后反而天天有人翻。最后分享两个我一直在用的小技巧。一是切分前先做个试切把每片行数设成很小的值比如 20 行快速跑一遍看看表头对不对、字段有没有跑偏、格式有没有保留确认没问题再调回正常参数跑全量。这一步花十几秒能挡住大部分低级错误。二是给输出文件加一个总览表把所有分片的文件名、数据行数、首行关键字段值汇总成一张小表放在输出目录里交付的时候连同这张表一起发出去对方一眼就能知道每一份装的是什么不用逐个点开翻。这两个习惯都是踩坑踩出来的。试切那一条源于一次参数填错导致 40 个文件全部重跑总览表那一条源于被追问了十几次哪个文件里有某区域的记录。工具好写习惯难养但这两样确实省下了后面大量的沟通成本。
1. 需求场景拆解什么情况下非要把 Excel 切开1.1 四种高频切分场景看看你中了几个Excel 按行切分这件事听着像小需求但只要你在数据岗待过一段时间就会发现它几乎是每个月底的固定动作。我把过去几年遇到过的情况归了归类大致跑不出下面四种。第一种是导入限制触发的被动切分。不少业务系统的导入模板对单文件行数有硬性限制超过就直接报错或者静默截断一半数据那种导进去了但少了一半最要命因为不看回执根本发现不了。这时就必须把一张几十万行的明细拆成若干个小文件一个个喂进去。第二种是分发需求导致的切分。比如一张全量客户对账单需要按区域或者按负责的销售拆成多个文件分别发给不同的人。全量发出去既没意义也不安全每个人只看自己那一块就行。这种切分的依据不是行数而是某个字段的取值。第三种是性能问题倒逼的切分。一个两三百万行的表打开要等半分钟随便筛一下又卡住公式一多直接假死。这时候与其硬扛不如按时间或者按业务编号切成若干张单表控制在十万行以内操作体验立刻回来。第四种是送审送检的格式要求。某些流程要求提交的文件每份不得超过固定大小或者每份只能包含固定条数的记录一条不多一条不少。这种对切得准的要求最高多一行少一行都要返工。这四种场景看起来都是把大文件变小文件但切分的依据、对格式的要求、出错后的代价完全不同。想清楚自己属于哪一类后面的方案选型才不会走弯路。1.2 手工切分的成本账为什么必须工具化有人会想不就是复制粘贴吗插几行空行分一分不就完了。我算过一次账结论是这条路基本走不通。假设一个 12 万行的表要按每 5000 行切一份共 24 份。手工流程是定位到第 5001 行、选中剩余所有内容、剪切、新建工作簿、粘贴、另存为、命名、关掉。熟练的人一份大概 40 秒24 份接近 20 分钟。这还不是最糟的最糟的是中途被打断回来忘了切到第几行了只能从头核对。更要命的是准确性。手工操作里最容易出的事故是剪切时的选区偏移导致某一行重复出现在两个文件里或者某一行直接消失。12 万行的数据少一行多一行肉眼根本看不出来等到下游对不上账才发现回溯成本远高于当初写个脚本的时间。还有一次性的问题这个月切完了下个月数据一更新全部重来。所以我的判断很简单——只要这个动作发生第二次就值得写成工具。第一次可以手工验证逻辑对不对第二次开始一律跑脚本。写脚本的投入大概是一两个小时换来的是每次几十秒出结果而且结果稳定可复现。这笔账怎么算都划算。1.3 切分粒度怎么定行数、大小还是业务键定了要工具化下一个问题就是按什么标准切。这个决策直接决定了工具的设计选错了后面怎么调都别扭。按固定行数切是最通用的一种每 N 行一个文件不管内容是什么。它适合纯导入场景因为下游只关心每个文件不超过多少行。N 的取值一般看下游限制留 10% 到 20% 的余量比较稳妥比如限制 5000 行就按 4500 切。按文件大小切更适合走传输渠道的场景。行数和大小不是线性关系一行全是长文本和一行全是数字体积能差十几倍。如果你的约束是每个文件不超过 5MB那就得按字节算边写边累加体积超过阈值就换下一个文件。按业务键分组切是另一套逻辑常见的是按日期、按区域、按部门。这种切法的特点是每份文件的大小完全不可控——热门区域的记录可能是冷门区域的几十倍。所以实践中通常是两级策略先按业务键分组组内再按行数二次切分组太大就继续拆组太小可以考虑合并。我个人的默认配置是数据类文件按行数切分发类文件按业务键切交付类文件两者结合。这个默认值覆盖了大概八成的情况剩下的两成再单独调。2. 方案选型三条路线各自的适用边界2.1 路线一办公软件内置功能与 Power Query先说不用写代码的路子因为很多人被要装 Python这一步劝退了。主流办公套件里部分版本确实内置了拆分工作表的功能一般藏在数据选项卡或者工具箱里。它的优点是零门槛点几下就出结果缺点是参数非常死通常只支持按固定行数或者按某列的不同取值没法做复杂逻辑比如跳过前三行标题、从第四行开始算、每份保留表头。而且不同版本的功能位置和命名还不一样换个环境就找不到了。更靠谱的无代码方案是Power Query。它的思路是把切分变成一次数据变换先给数据加一个索引列然后用索引除以每份行数取整得到一个分组号列再按这个分组号分组最后把每组导成一个独立的表或者文件。整个过程有记录、可复用数据更新了只要刷新一下。Power Query 的优势在于它是办公软件原生能力不需要额外环境同事接手也能看懂步骤。它的短板也很明显处理几十万行以上的数据时刷新速度会明显变慢而且导出成多个独立文件这一步原生界面支持得并不好通常还得配合一段简短的宏代码来实现批量另存。所以我的判断是数据量在十万行以内、逻辑简单、需要交付给非技术同事维护的优先 Power Query。超过这个量级或者逻辑里带条件判断的直接上脚本别在图形界面里绕。2.2 路线二脚本化处理openpyxl / pandas脚本路线是main力方案也是我实际工作中用得最多的。Python 生态里处理 Excel 最常用的两个库定位完全不同得分开说。pandas强在数据处理读进来就是一个二维表结构切片、筛选、分组都是一行代码的事。用它做切分核心代码可能就七八行。但它有个致命短板读写过程中格式基本全丢。字体、颜色、边框、列宽、条件格式、合并单元格统统保不住写出去的就是一张干干净净的裸表。如果你的表只是纯数据这反而正合适——快、简单、体积小。openpyxl强在文件结构层面能读到工作簿的每一个细节样式、公式、批注、超链接都能拿到。它支持流式读写模式处理大文件时内存占用控制得很好。代价是 API 相对啰嗦写个切分脚本大概要五六十行而且逐单元格复制样式会明显拖慢速度。我的实际组合是纯数据切分用 pandas需要保留格式的用 openpyxl。两条路都准备着遇到什么活用什么工具不用强行统一。2.3 三条路线的横向对比表把几种方案摆在一起对比选型的时候能少纠结。维度办公软件内置功能Power Querypandasopenpyxl上手门槛极低低中中是否需要额外环境否否是是十万行以内速度快较快很快快百万行级别基本不可用很慢内存吃紧流式模式可扛格式保留部分保留基本不保留不保留可完整保留复杂逻辑支持无中等强强可维护性差好好好批量输出多文件一般需配合宏好好表格里最值得注意的一行是百万行级别。很多人踩的坑是拿 pandas 硬读一个两百万行的表机器内存不够直接崩掉还以为是代码写错了。实际上 pandas 读 Excel 是先把整个文件解开成对象再转换峰值内存大概是文件体积的十几倍一个 50MB 的表就可能吃掉 800MB 以上内存。这种情况必须换 openpyxl 的只读流式模式它是一行一行吐数据内存占用基本恒定。3. 核心实现按行切分脚本的关键细节3.1 环境准备与库版本环境这块没什么玄机但版本对不上会浪费很多时间排查。python -m venv venv source venv/bin/activate # Windows 下用 venv\Scripts\activate pip install openpyxl pandas我一般会顺手把版本固定下来写进一个依赖文件里。原因是 openpyxl 在 3.x 的几个小版本之间只读模式对某些特殊文件的行为有过变化尤其是带大量合并单元格的表格老版本会直接抛异常。固定版本能保证今天能跑的脚本半年后同事拿去也能跑。pip freeze requirements.txt还有一个容易被忽略的点处理 Excel 的机器上不一定要装办公软件。openpyxl 是纯 Python 实现不依赖任何本地组件扔到服务器上照样跑。这点在做定时任务的时候特别有用——不用为了跑个切分脚本在服务器上装一整套办公套件。3.2 表头定位别只写 header1这一段是真实踩过的坑值得单独拎出来说。几乎所有教程里的切分示例都默认第一行是表头第 1 行开始是数据。但真实业务表格里第一行很可能是标题2024 年某季度销售明细表第二行是制表人和日期第三行才是真正的字段名第四行开始才是数据。你按第一行表头去切切出来的每个文件都带着一行大标题和一行日期导入下游系统百分百报错。所以我的做法是表头行数和数据起始行一律做成显式参数不猜。HEADER_ROWS 3 # 前 3 行作为表头每份文件都重复写入 DATA_START_ROW 4 # 从第 4 行开始算数据判断表头到哪一行为止有个很土但很有效的办法看第一列从哪一行开始往下都是同类型的东西。标题行第一列通常只有一个格子有内容后面全是空字段名那一行第一列是个短词数据行第一列是具体的编号或者名称。人工扫一眼就能定定完写死别在代码里做启发式猜测那玩意儿在边界情况下比人不可靠。还有一类表更阴险中间夹着小计行或者空行。这种表在切分前必须先清洗把所有非数据行剔掉否则切出来的分片里会混进小计行下游一算总和就翻倍。我的处理习惯是先跑一遍清洗把数据规整成首行字段名 纯数据的标准形态再进入切分流程。多一步但省心。3.3 主流程代码与逐段解释下面这份是按固定行数切分的完整实现用的是 openpyxl 的流式读写模式几十万行也不至于把内存吃爆。import os from openpyxl import load_workbook, Workbook def split_by_rows(src_path, out_dir, rows_per_file5000, header_rows1, sheet_nameNone, prefixNone): src_path 源文件路径 out_dir 输出目录 rows_per_file 每个分片包含的数据行数不含表头 header_rows 表头占用的行数每份分片都重复写入 sheet_name 指定工作表None 表示取第一个 prefix 输出文件名前缀None 表示用源文件名 os.makedirs(out_dir, exist_okTrue) base prefix or os.path.splitext(os.path.basename(src_path))[0] wb_in load_workbook(src_path, read_onlyTrue, data_onlyTrue) ws_in wb_in[sheet_name] if sheet_name else wb_in.worksheets[0] row_iter ws_in.iter_rows(values_onlyTrue) # 先把表头抓出来存着后面每份都要重写 headers [] for _ in range(header_rows): headers.append(list(next(row_iter))) part_no 1 buffer [] def flush(buf, idx): wb_out Workbook(write_onlyTrue) ws_out wb_out.create_sheet(title(ws_in.title or Sheet1)[:31]) for h in headers: ws_out.append(h) for r in buf: ws_out.append(list(r)) name f{base}_part{idx:03d}.xlsx path os.path.join(out_dir, name) wb_out.save(path) print(f[OK] {name} 数据行数 {len(buf)}) return path for row in row_iter: if row is None: continue # 全空行直接丢弃避免污染分片 if all(v is None or str(v).strip() for v in row): continue buffer.append(row) if len(buffer) rows_per_file: flush(buffer, part_no) part_no 1 buffer [] if buffer: flush(buffer, part_no) else: print([WARN] 没有剩余数据最后一片未生成) wb_in.close()逐段说一下为什么这么写。read_onlyTrue是性能关键。开着这个模式openpyxl 不会把整个工作表解析成对象树而是按行流式吐数据内存占用基本恒定。代价是这时候不能改单元格、不能读样式只能读值。切分场景恰好只需要值所以这个取舍完全划算。data_onlyTrue处理的是公式问题。很表里的关键列是公式算出来的不加这个参数读到的就是VLOOKUP(...)这串字符串写出去下游全是错的。加了之后读的是缓存值但有个前提条件这个文件必须曾经被办公软件打开并保存过。如果文件是程序直接生成的、从没被打开过缓存值压根不存在读出来是None。这个坑我栽过一次排查了大半天最后发现是上游系统导出时没计算公式。iter_rows(values_onlyTrue)省掉了单元格对象直接返回值的元组速度快不少。全空行过滤那几行别小看。真实表格里经常出现看着没数据但实际有格式的行或者中间的一段间隔行不过滤的话会被当成数据行数进去导致每份分片的实际有效行数少于预期。write_onlyTrue同样是流式写入配合ws.append()一行一行推。注意这个模式下不能读回刚写的内容也不能合并单元格所以样式相关的操作要提前想清楚。3.4 保留格式的进阶写法有些场景必须保格式比如带底色标记的异常记录、带边框的报表模板、带条件格式的看板。这时候write_only和values_only都得关掉改成逐单元格搬运。from openpyxl import load_workbook def copy_row_with_style(ws_in, ws_out, row_idx): for col_idx, cell in enumerate(ws_in[row_idx], start1): new_cell ws_out.cell(rowrow_idx, columncol_idx, valuecell.value) if cell.has_style: new_cell.font cell.font.copy() new_cell.fill cell.fill.copy() new_cell.border cell.border.copy() new_cell.alignment cell.alignment.copy() new_cell.number_format cell.number_format这段逻辑本身不复杂但性能代价非常大。样式复制要反复创建对象实测下来比纯值写入慢五到十倍。一个 20 万行、30 列的表纯值写入大概十几秒带样式搬运要两三分钟如果还有大量条件格式时间还得往上翻。我的做法是分级处理表头行一定要搬样式因为它是每份文件的脸面格式错了很显眼数据行只搬数字格式和填充色这两个下游最常校验字体和边框一律放弃。这样能省掉一大半时间效果上也能应付绝大多数场景。合并单元格要单独提醒一句。如果你的表头里有合并单元格比如基本信息横跨三列直接按原样逐格搬运会报错必须先读一次合并区域列表在新工作簿里重建同样的合并区域。这块代码稍微绕我一般建议能用取消合并 居中对齐伪装的就别用真合并省事很多。3.5 参数计算文件大小估算与分片数rows_per_file这个参数别拍脑袋定估一下更稳。Excel 单工作表的上限是 1048576 行、16384 列超过这个数保存都会失败。所以如果你的源表接近这个量级切分不是可选项而是必须项。文件体积的粗估可以用这个经验公式每 1 万行 × 每行 20 列的数据量xlsx 格式大约在 1.5MB 到 3MB 之间。变量主要来自单元格内容的平均长度和一列里长文本的比例。如果一列是备注字段、单格动辄上百字那体积会明显偏大。分片数就是总行数除以每片行数向上取整import math total_rows 123456 rows_per_file 5000 part_count math.ceil(total_rows / rows_per_file) print(part_count) # 25留余量的习惯我一直保持着。下游说限制 5000 行我就按 4500 切因为下游的计数口径可能和我不一样——它可能把表头也数成一行也可能把空行算进去。留 10% 的缓冲比自己反复调试省事得多。4. 实操记录一次20万行数据的完整切分过程4.1 前置检查清单正式跑之前我有一套固定的检查动作五分钟能做完但能挡掉大部分事故。第一确认总行数和有效行数。用办公软件打开拉到最底下看看再配合脚本读一遍计数两个数对不上就说明有隐藏行或者中间的空行干扰得先搞清楚。第二确认表头行数和字段数。数一下列数看看有没有隐藏列。隐藏列这事特别隐蔽肉眼看不见但在文件里是存在的切完之后突然多出来一列追查起来很费劲。第三检查有没有公式依赖跨表引用。如果某一列的值是靠引用另一个工作表算出来的切分时那个被引用的表没被带过去值就变成None或者#REF!。解决办法是切分前先把公式列转成值。第四确认输出目录有写权限而且要留足空间。20 万行的表切出 40 多个文件加起来体积可能比源文件还大每个文件都有自己的结构开销。第五定好命名规则并写下来。源文件名_part001.xlsx这种带三位序号的格式是我一直在用的好处是文件管理器里排序天然正确不会出现 part10 排在 part2 前面那种尴尬。这套检查我最初是凭记忆做的漏过两次之后老老实实写成了一张清单贴在显示器边上。清单化的好处是换台机器、换个人流程一样。4.2 执行与耗时实测那次的源文件是 203,847 行、26 列的订单明细体积 89MB包含日期、金额、编号、备注四类字段备注列平均长度在 40 字左右。参数定为rows_per_file5000、header_rows1理论上会切出 41 个文件最后一片只有 3847 行。实测耗时分布大概是这样阶段耗时说明打开文件并进入只读模式约 2 秒只解析结构不加载数据逐行读取并缓冲约 25 秒大头是解析 XML写入 41 个文件约 18 秒每片约 0.4 秒合计约 45 秒内存峰值约 180MB45 秒对比手工操作的两三个小时量级差异不用多说。内存峰值 180MB 也在可控范围内随便一台普通办公机都能扛。这里有个细节值得说整体耗时的大头在读不在写。因为是流式读取每读一行都要走一遍 XML 解析26 列就是 26 次取值。如果列数更多或者单元格内容更长这个时间还会涨。想提速的话最有效的办法是先把源文件转成 CSV 再处理CSV 的解析速度比 xlsx 快一个数量级处理完再转回 xlsx。当然这么做的前提是格式不重要。4.3 结果校验方法切完不校验等于没做这是我最坚持的一条。最简单的校验是行数求和。把 41 个分片的有效数据行数加起来必须等于源文件的有效数据行数。import os, glob from openpyxl import load_workbook total 0 for f in sorted(glob.glob(output/*.xlsx)): wb load_workbook(f, read_onlyTrue, data_onlyTrue) ws wb.worksheets[0] cnt sum(1 for _ in ws.iter_rows(min_row2, values_onlyTrue)) print(os.path.basename(f), cnt) total cnt wb.close() print(合计:, total)第二个校验是关键字段去重计数。挑一个理论上唯一的字段订单号、流水号之类把所有分片里的这个字段汇总起来去重去重后的数量应该和总行数一致。不一致就说明有重复行多半是切分时的边界处理有问题。第三个校验是抽样比对首尾。每个分片的第一行和最后一行拿回源文件核对一下看看是不是连续。这一步能抓出漏行和错位两类问题而且人工看几眼就能确认比写脚本快。三个校验都过我才认为这次切分是成功的。多花五分钟换来的是不用在下游报错时手忙脚乱。5. 踩坑手册数据不失真的十个细节5.1 数据失真类问题这一类最恶心因为文件能打开、能导入、不报错但数据本身已经悄悄变形了。长数字变科学计数法。订单号、银行卡号、身份证号这类 15 位以上的数字写出来经常变成1.23457E18。根子在类型判断上——写入时如果值是个数字类型Excel 会按数值处理并按列宽显示。解决办法是在写入前统一转成字符串并且在写完后把该列的数字格式设成文本。这个坑我在一个银行卡号字段上栽过几十万条数据全部报废只能重跑。前导零丢失。001234写进去变成1234看着是小问题但如果下游拿这个当主键匹配全崩。同样是文本格式的问题处理方式和上一条一样。日期变成一串数字。Excel 内部把日期存成序列号2024-01-01 实际是 45292。如果读的时候拿到的不是 datetime 对象而是个整数写出去就是 45292 这种鬼东西。openpyxl 一般能正确识别但如果单元格被设成了常规格式就识别不出来。稳妥的做法是读的时候判一下列名或者值范围必要时手动转换。超长文本被截断。Excel 单元格的字符上限是 32767 个超过就直接丢。注释类字段偶尔会撞上这个限制。切分前扫一遍最长的那几格心里有个数。5.2 结构丢失类问题合并单元格直接报错。前面提过write_only模式完全不支持合并普通模式下也得手动重建。撞上这个错误的典型表现是脚本跑到一半抛异常然后你发现源文件的表头长得像千层饼。条件格式全部失效。用 pandas 处理的话条件格式、数据验证、批注、超链接这四样东西一定全丢因为这个库压根不看这些信息。需要保留就得走 openpyxl 逐格搬运而且条件格式还得单独用formatting相关的 API 重建代码量不小。列宽变成默认值。这是个不影响功能但很影响观感的问题。切出来的文件每列都是标准宽度文字挤在一起或者留出大片空白。补救办法很简单写完之后遍历一遍所有列按内容长度的粗略估计设一下for col in ws_out.columns: max_len 0 letter col[0].column_letter for cell in col[:200]: # 只看前 200 行够用了 if cell.value is not None: max_len max(max_len, len(str(cell.value))) ws_out.column_dimensions[letter].width min(max(max_len * 1.2, 8), 50)打印区域和页眉页脚丢失。这个只有做正式报表交付时才会在意普通数据处理忽略即可。5.3 性能与稳定性问题内存爆掉。前面算过pandas 读 Excel 的峰值内存大概是文件体积的十几倍。一个 60MB 的表在 8GB 内存的机器上跑很容易触发换页慢得像死机。换 openpyxl 的流式模式能解决代价是代码长一点。max_row返回 None。只读模式下这个属性并不总是可靠如果文件生成时没写 dimension 信息或者被某些工具改过max_row可能返回一个错误的数甚至直接报错。所以分片数别用max_row算老老实实边读边计数。写入时文件被占用。如果输出目录里已经有一个同名文件被打开了哪怕只是预览窗格开着保存会抛权限错误。脚本里加个 try 捕获提示请关闭已打开的输出文件比抛一堆堆栈信息友好得多。磁盘空间不够。切分是一变多总体积通常会膨胀 10% 到 30%因为每个文件都有自己的结构头和共享字符串表。源文件 1GB输出目录至少留 1.5GB。5.4 常见问题速查表把上面这些整理成一张表出问题的时候按症状查比翻代码快。症状最可能的原因处理方向长数字变成科学计数法按数值写入转字符串 设文本格式前导零消失同上同上日期显示为整数单元格格式为常规显式转 datetime 或设日期格式分片里出现无关的小计行源表未清洗切分前先过滤非数据行公式列全是 None文件从未被办公软件打开保存先手工打开保存一次或让上游改导出方式脚本跑到一半报错表头有合并单元格关闭只读写入模式并重建合并区域处理速度极慢逐格读样式只保留必要样式其余放弃内存占用持续上涨用了普通读取模式改read_onlyTrue保存报权限错误输出文件被占用关闭预览窗格或已打开的文件每份分片少几行空行被当成数据计入增加全空行过滤6. 交付给别人用把它做成傻瓜工具6.1 参数化与配置文件脚本自己用怎么都好说一旦要交给同事参数就得从代码里搬出来。我一般把配置写成一个独立的文本文件或者命令行参数最少包含这几项源文件路径、输出目录、每片行数、表头行数、工作表名称。这样改需求的时候不用碰代码改一行配置就行。import argparse parser argparse.ArgumentParser(description按行切分 Excel) parser.add_argument(-i, --input, requiredTrue, help源文件路径) parser.add_argument(-o, --output, defaultoutput, help输出目录) parser.add_argument(-n, --rows, typeint, default5000, help每片数据行数) parser.add_argument(-h-row, --header-rows, typeint, default1, help表头行数) parser.add_argument(-s, --sheet, defaultNone, help工作表名称) args parser.parse_args()用起来就是一句命令python split_excel.py -i 源数据.xlsx -o 输出 -n 4500 -h-row 3比让同事去代码里找ROWS_PER_FILE 5000这一行改数字体验好太多了。再往上一步是做成可视化界面。用 Python 自带的图形库搭个简单的窗口选文件、填数字、点按钮二十分钟能写完。这一步的价值不在于技术含量而在于让不会用命令行的人也能自助操作。我做过一次之后同组同事再也不来问能不能帮我切一下了。6.2 日志与异常提示怎么写工具交付出去之后最花时间的不是写代码是回答为什么我这边报错了。所以日志和错误提示必须写得像人话。原则一打进度别打细节。每一片写完打一行已生成 xxx_part005.xlsx数据行数 4500跑一万行能出几行不多不少。别打每一行的日志几十万行输出刷屏真出问题反而找不到。原则二错误信息要带位置。与其打一个KeyError不如打读取失败指定工作表 明细 在文件中不存在当前文件包含的工作表有明细表、汇总、参数。第二句能直接让人自己解决第一句只能来找你。try: ws wb[sheet_name] except KeyError: names 、.join(wb.sheetnames) raise SystemExit(f未找到工作表 [{sheet_name}]当前文件包含{names})原则三结束给个总结。跑完了打一行共生成 41 个文件合计 203847 行输出目录xxx。这一行是用户唯一的确认信号没有它用户永远不确定是不是跑完了。最后是个经验把日志同时写进文件。窗口一关日志就没了出问题时用户根本说不清发生了什么。留一份run.log在输出目录里事后能复盘。6.3 使用说明文档的模板给非技术同事的工具一份一页纸的说明基本是必需品。我通常按这个结构写不用长但要能照着做。第一段写这个工具干什么把一个大 Excel 按指定行数拆成多个小文件每份都保留表头。一句话讲清楚不讲原理。第二段写怎么用用截图配三步双击启动、选文件、填数字点开始。每一步配一张图不写文字也能看懂。第三段写结果在哪明确说明输出文件在源文件同目录下的output文件夹里命名规则是什么样。第四段写常见情况列三到五条最可能遇到的文件正被打开会失败、表头行数填错了怎么办、处理大文件需要等一会儿别重复点击。第五段写找谁。留个联系方式别留一堆技术细节用户不需要。这份说明我自己看过好几遍越写越短。最初写了三页后来发现没人看压到一页之后反而天天有人翻。最后分享两个我一直在用的小技巧。一是切分前先做个试切把每片行数设成很小的值比如 20 行快速跑一遍看看表头对不对、字段有没有跑偏、格式有没有保留确认没问题再调回正常参数跑全量。这一步花十几秒能挡住大部分低级错误。二是给输出文件加一个总览表把所有分片的文件名、数据行数、首行关键字段值汇总成一张小表放在输出目录里交付的时候连同这张表一起发出去对方一眼就能知道每一份装的是什么不用逐个点开翻。这两个习惯都是踩坑踩出来的。试切那一条源于一次参数填错导致 40 个文件全部重跑总览表那一条源于被追问了十几次哪个文件里有某区域的记录。工具好写习惯难养但这两样确实省下了后面大量的沟通成本。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
