pep8的79字符限制是历史妥协而非硬性要求，关键在于团队配置一致；snake_case与pascalcase体现语义分层；空行规则降低git diff噪声；import分组顺序提升可维护性。
为什么 max_line_length=79 不是硬性限制而是历史妥协
PEP8 里推荐单行不超过 79 个字符，不是因为 Python 解析器有这个限制，而是为了适配老式终端和并排查看 diff 的场景。现在多数人用宽屏 IDE，black 默认用 88，flake8 也常配成 88 或 99——但关键不在数字本身，而在「一致性」：团队所有人的编辑器、linter、pre-commit 都得对齐同一数值，否则 git blame 会把换行调整也记成“修改”，干扰真实逻辑变更。
常见错误现象：flake8 报 E501 line too long，但同事本地不报——八成是 .flake8 配置没进 git，或 VS Code 的 Python 扩展读了用户级配置覆盖了项目级。
- 检查是否真正在项目根目录放了
.flake8或pyproject.toml（含[tool.flake8]） - 运行
flake8 --config=.确认当前生效的配置路径 - 如果用
black，它默认忽略E501，所以不能只靠它保格式；需搭配flake8或pylint做行长校验
snake_case 为什么强制用于函数和变量，却允许 PascalCase 类名
这是语义分层设计：小写+下划线表示「可调用的、过程性的动作」，大驼峰表示「抽象的、有边界的实体」。Python 解释器不强制，但 import 机制和文档工具（如 sphinx）依赖这种命名暗示做自动分类。比如 requests.Session 是类，requests.session() 是工厂函数——名字不同，用途和生命周期就天然区分开。
容易踩的坑：写测试时习惯性给 fixture 起 PascalCase 名（如 @pytest.fixture def MyData():），结果 pytest 按变量处理，IDE 不提示类型，pylint 直接报 C0103 invalid-name。
立即学习“Python免费学习笔记（深入）”；
- 函数、变量、参数、模块名必须
snake_case - 类、异常、type alias（如
UserId = int）用PascalCase - 常量（全大写+下划线）仅限真正不变的值，比如
MAX_RETRY = 3；别把配置项（如API_TIMEOUT）也当常量，它可能被环境变量覆盖
空行规则背后的协作成本考量
PEP8 要求顶层函数/类之间空两行、方法之间空一行，不是为了“看起来清爽”，而是降低 git diff 噪声。如果两个函数紧贴着写，加一个新函数插在中间，diff 会同时标记前一个函数末尾和后一个函数开头为“变化”，实际只动了一处。
使用场景：多人协作的大型代码库中，git log -L 查某段逻辑的演进时，清晰的空行能快速锚定函数边界，避免误判修改范围。
- 类内部方法间必须空一行，哪怕只有
def __init__(self): pass - 类定义前空两行，但如果它紧跟在
if __name__ == "__main__":后面，可以只空一行（PEP8 明确允许此例外） - 不要用空行分隔逻辑块（比如“先处理输入，再调用 API”），那是注释或函数拆分的事；空行只表达结构层级，不表达业务意图
import 分组顺序为什么影响可维护性
标准库 → 第三方库 → 本地应用/库，这个顺序不是为了“显得专业”，而是让 grep 和 IDE 快速定位依赖来源。比如线上出错时查 ImportError，一眼就能看出是缺系统包（ssl）、还是 pip 没装对（requests）、或是相对导入路径错了（from .utils import retry）。
性能影响很小，但兼容性风险真实存在：某些打包工具（如 pyinstaller）按 import 顺序分析依赖树，乱序可能导致子模块未被收录。
- 每组内按字母序排列，
import os必须在import sys前面 - 禁止
from module import *，它会让静态分析失效，且和__all__冲突 - 循环引用常源于把本该在函数内 import 的第三方模块提到文件顶部——不是规范问题，是设计问题；规范只管怎么写，不管怎么想
真正难的从来不是记住这些规则，而是当 PR 被 CI 因 E302 expected 2 blank lines 拒绝时，你得立刻判断：这是格式问题，还是刚才删掉的那个空行下面其实藏着没被测试覆盖的边界逻辑？
