必须将pep 8检查嵌入开发流程：本地用pre-commit+black/flake8拦截提交，ci中强制校验并锁死工具版本；明确区分强制项（如行宽88、4空格缩进）与可协商项（如引号风格），杜绝“假装合规”和新人踩坑。
怎么让团队真正在写代码时遵守 PEP 8
靠文档和口头提醒没用，必须把检查嵌进开发流程里。核心是：本地提交前自动拦截 + CI 阶段强制拒绝。
- 用
pre-commit在git commit前跑black+flake8，开发者改完代码一提交就立刻报错，不格式化/不修复就过不去 -
pyproject.toml里统一配line-Length = 88、skip-String-normalization = true等关键项，避免各人setup.cfg或tox.ini冲突 - 别用
autopep8—— 它会瞎改逻辑（比如把if x == 1:拆成多行再加括号），black虽激进但确定性高
哪些 PEP 8 条款必须强制，哪些可以商量
强制项直接关系到可读性和协作效率，妥协只会积累技术债；非强制项留出空间，否则开发者会绕开工具。
- 必须强制：
max-line-length（建议 88）、indentation（4 空格）、blank-lines（函数间双空行）、function-name（snake_case） - 可协商：
import-order（只要统一用isort就行，顺序规则可在pyproject.toml里调）、quotes（单引双引都行，但整个项目得一致） - 别碰：
variable-name里的缩写豁免（如id,url,err），硬改成identifier、uniform_resource_locator反而降低可读性
CI 流水线里怎么防“假装合规”
有人会跳过 pre-commit、手动格式化后删掉 .pre-commit-config.yaml，或者只在 CI 里跑检查却不阻断构建——这等于没执行。
- CI 脚本里必须加一步：
black --check --diff .和flake8 .，任一失败就exit 1 - 禁止用
pip install black动态装工具，统一用poetry或pip-tools锁死black==24.4.2版本，不同版本对同一段代码的格式化结果可能不一致 - 别信 “CI 通过就行”，要查日志里是否真执行了检查命令——有些配置把
flake8写成flak8，拼错也不报错，只是静默跳过
团队新人最容易栽在哪几个点
老手默认知道的边界，新人常因信息差反复踩坑，不是态度问题，是工具没兜底。
立即学习“Python免费学习笔记（深入）”；
-
__init__.py文件里写业务逻辑 —— PEP 8 明确说它该空着或只放__all__，但新人常在这儿 import 全局变量，导致循环引用难排查 - 用
is判断None以外的值（如if x is True:），pylint会报literal-comparison，但flake8不管，得靠pyproject.toml里显式启用pylint插件 - 类型注解写成
def foo(x: List[str]) -> Dict[str, int]:而不是from typing import List, Dict，python 3.9+ 应该用内置list[str]，否则mypy在不同 Python 版本下行为不一致
事情说清了就结束。真正难的不是定规范，是让每次 git push 都变成一次无声的审查——工具链得严丝合缝，漏一个环节，规范就变成墙上的纸。