在Python开发中，单个 .py 文件究竟写多少行最合适，并没有一个绝对的强制标准（官方PEP 8规范也没有规定文件行数上限），但业界普遍遵循一套基于可读性和单一职责原则的经验法则。
一般来说，主流的建议范围是：200行 到 500行 最佳，尽量不要超过 1000行。
以下是具体的层级划分和背后的工程考量：
- 经验法则与行数参考
< 200 行（非常优秀）：文件职责极其清晰，通常只包含一个主要的类（Class）或一组高内聚的辅助函数。阅读者可以毫无压力地通读并理解整个文件的上下文。
200 - 500 行（最常见、最合理）：这是大多数良好重构的 Python 项目中 .py 文件的常态。能够容纳包含几个相关类、核心业务逻辑或完整 API 端点的模块。
500 - 1000 行（警告区间）：文件开始变得臃肿。如果是定义复杂的类或包含大量注释和文档字符串（Docstrings），这还可以接受；但如果是密集的逻辑代码，开发者在上下滚动找代码时会开始感到疲惫（心智负担增加）。
1000 行（“上帝模块” / God Module）：通常是一个强烈的代码坏味道（Code Smell）。这说明这个文件很可能承担了太多的职责（比如同时处理数据库连接、业务逻辑和网络请求）。强烈建议进行拆分（重构）。
- 比行数更重要的衡量标准
不要为了凑行数而刻意拆分代码，决定一个文件是否需要拆分，更应该看以下几个原则：
A. 单一职责原则 (Single Responsibility Principle, SRP)
一个 .py 文件（模块）应该只负责一个特定领域的事情。
错误示例：一个 utils.py 里既有日期格式化函数，又有数据库连接池代码，还有加密解密算法。（职责混乱）
正确示例：拆分成 date_utils.py、db_pool.py、crypto.py。
B. 认知负荷与滚动条测试
当你需要经常使用 Ctrl+F 或大量上下滚动才能搞清楚一个变量的来源或一个函数的调用链路时，说明文件太长了。
大脑的短期记忆容量有限，如果阅读文件底部的代码时，已经忘了顶部的全局配置是什么，就该拆分了。
C. Import 依赖的数量
如果你的 .py 文件顶部有超过 20-30 行的 import 语句，导入了各种毫不相干的第三方库，这通常意味着这个模块做的事情太多了。 - 如何优雅地拆分大型 .py 文件？
如果你发现某个 main.py 或 app.py 已经突破了 1000 行，Python 提供了极其优雅的包（Package）管理机制来帮你重构：
重构前：
code
Text
my_project/
└── core_logic.py # 1500 行，包含了模型、验证器、业务逻辑
重构后（利用 init.py 保持外部调用方式不变）：
code
Text
my_project/
└── core_logic/
├── init.py # 暴露对外的 API：from .models import User ...
├── models.py # 300 行：只定义数据类
├── validators.py # 200 行：只做数据校验
└── services.py # 400 行：具体的业务流程
外部代码依然可以使用 from my_project.core_logic import User，但内部代码已经实现了完美的解耦。 - 有没有允许“超长文件”的例外？
有的，以下情况即使超过 1000 行也可以接受，甚至是不建议盲目拆分的：
自动生成的代码：例如由 Protobuf、Thrift 或 ORM 工具自动生成的 .py 文件，往往有几千行，人类不需要去阅读和修改它。
配置/字典映射文件：例如包含全国城市代码映射的巨大字典，由于没有复杂的逻辑，全塞在一个文件里反而便于管理。
单文件脚本（Single-file script）：如果是发给运维同事执行的临时脚本，为了避免打包和依赖问题，要求“开箱即用”，通常会把所有逻辑揉在一个文件里。
特定的框架约定：比如早期 Django 项目中巨大的 models.py 或 views.py（不过现在的最佳实践也是将其拆分为 models/ 目录）。
总结
“高内聚，低耦合” 永远是第一指导原则。把行数控制在 500行以内 是保持代码整洁的绝佳习惯。当文件超过这个界限时，停下来问问自己：“这个文件是不是管得太多了？”