应流式分块处理超大文件：按行或字节切分，用with双层上下文管理器、enumerate计行、保留换行符；含超长行时回退至最近 切分；命名带偏移、原子重命名防覆盖；切分逻辑须匹配下游消费需求。
用 open() 按行分块读写，避免内存爆炸
直接 readlines() 或 read() 整个超大文件（比如 10GB+）会瞬间吃光内存，Python 进程被系统 kill 是常见结果。必须流式处理：逐行读、累积到指定行数后写入新文件，再清空缓冲。
关键不是“怎么切”，而是“怎么不崩”。推荐用 with open(...) 套两层上下文管理器：外层读源文件，内层按需打开新输出文件。
- 每读
n行就关闭当前输出文件，再开下一个，防止句柄泄漏 - 用
enumerate()计行比手动count += 1更安全，避免漏行或错位 - 行末换行符保留原样，别用
line.strip()再加
按字节数分割更稳定，尤其含二进制或超长行时
按行切在遇到单行几百 MB 的日志（如 minified JSON、base64 块）时会失效：for line in f 可能卡死或 OOM。此时应放弃“行”概念，改用固定字节块（如每 50MB 一个文件）。
注意 read(n) 返回的是字节（bytes），若原文件是文本且含 UTF-8 多字节字符，直接截断可能产生乱码。稳妥做法是：在接近边界处回退，找到最近的完整换行符再切分。
- 用
f.tell()记录当前位置，每次read(8192)小块读取，拼接后找 - 不要依赖
os.path.getsize()预算总块数 —— 文件可能被其他进程追加，边读边切更可靠 - 输出文件名建议带起始偏移，如
part_00000000_0052428800.bin，方便后续校验
split 命令快但不可控，Python 脚本才是生产环境首选
Linux 下 split -l 100000 big.log part_ 确实快，但它无法处理编码转换、BOM 清理、行首过滤等需求，且 Windows 无原生支持。一旦要加逻辑（比如跳过注释行、只保留含 "ERROR" 的行），就得切回 Python。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
真正需要脚本的原因不是“不能用命令”，而是“后续流程要复用中间状态”。例如：切完立刻计算每个小文件的 MD5、并发上传到 S3、触发下游 Spark 任务 —— 这些都得靠 Python 控制流衔接。
- 别用
subprocess.run(['split', ...])包裹 —— 错误码难捕获，路径空格/特殊字符易出错 - 如果只是临时调试，
split可以快速验证切分逻辑是否合理，但上线必须替换为纯 Python 实现 - 注意
split默认按行，-b按字节，两者行为差异极大，文档里写的是“lines”，实际日志里“line”未必是你以为的那条
文件名生成与覆盖风险必须显式处理
默认用 part_001.txt 这类命名，若脚本中断重跑，旧文件可能残留，导致部分数据重复写入或遗漏。Python 不会自动帮你判断“这个文件是不是上次没写完”。
最简方案是：先扫描目标目录，用 glob.glob("part_*.txt") 找出已有文件，取最大序号续写；更稳的方式是写入临时名（如 part_001.tmp），全部写完再 os.replace() 原子重命名。
- 绝对不要用
os.remove()清空目录 —— 如果有其他程序正读这些文件，会触发PermissionError - Windows 下文件名长度限制为 260 字符，含完整路径；用
\?前缀可绕过，但多数库不兼容，建议控制前缀长度 - 如果输出路径在 NFS 或 SMB 共享盘上，
os.replace()可能降级为 copy+delete，需加try/except捕获OSError
实际最难的不是切分算法本身，而是你得想清楚：这些小文件之后交给谁处理？对方认不认你的分块逻辑？有没有人会手动打开第 37 个文件查问题？—— 分割方式必须和下游消费方式对齐，否则省下的内存，迟早会在 debug 时加倍奉还。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
