1. 为什么风格统一这件事比你想的更值钱先聊个我真实见过的场景。几年前我们团队接了个维护项目代码库年龄大概四岁前后经过七八个人的手。有人用四个空格有人用 Tab有人喜欢把函数参数一个挨一个地写在两行里还有人喜欢把整个 if 分支都挤成一行。每次做 Code Review最耗精力的不是业务逻辑而是大家在评论区里为了“这个缩进到底算不算对齐”来回讨论。你改我的格式我改你的格式最后 git 历史里多了几十个除了换行没有任何实际变更的提交。后来我和一个从大厂出来的同事聊起这个问题他说他们那边从某一天起强制上了Black约定俗成谁提交的代码不符合统一格式CI 直接红。团队里没有人再花时间讨论风格因为没得讨论。那个瞬间我才意识到代码格式化工具解决的根本不是“美丑”问题它解决的是协作成本问题。Python 社区里格式化工具其实不少autopep8、yapf、Black各有拥趸。但Black的定位和它们完全不同。它不是“帮你把代码改得符合 PEP 8 的建议”而是“直接剥夺你选择风格的权力”。用官方的话说它是一个uncompromising code formatter——不妥协、不让步。你给它一段 Python 代码它吐出一段格式完全确定的代码同样的输入永远得到同样的输出不管谁在什么机器上跑结果都一样。如果你一个人写独立项目说实话加不加格式化工具都无所谓反正代码只有你自己看。但只要是两人以上的协作或者你想让自己三个月后回看代码时少花点力气Black这种“独裁式”的格式化思路反而是最大的公平。它不看资历不看个人偏好不搞“我觉得这样读起来更顺”所有争议在工具层面就终结了。这篇文章就从原理、配置、踩坑、和其它工具搭配这几个维度把Black讲透。不是抄官方文档而是把我在真实项目里跑的细节、遇到的意外情况、以及最终沉淀下来的工作流都写出来。2. Black 到底按什么规则替你写代码先不急着配置搞清楚Black的内部逻辑会让你使用起来顺手得多。不然你会遇到一种很常见的困惑为什么我这段代码被它改成了这样为什么那行它就不动2.1 最核心的设计哲学结果必须可预测Black的设计者有个非常硬核的理念所有风格决策都应该由工具决定而不是由开发者决定。它不允许你通过配置文件去调整“缩进用几个空格”这类参数也不提供“左花括号要不要换行”的选项。市面上大部分格式化工具提供的是建议Black提供的是裁决。这个哲学带来一个直接结果团队成员之间不需要建立“我们约定好了超过 79 个字符就手动换行”这种口头契约。因为只要有人某个地方忘了遵守Black一跑就全给你收拾整齐。相比之下autopep8更像是一个温和的老师它指出你哪里不符合规范能改的顺手帮你改而Black是一台流水线机器无论什么样的毛坯件进去出来的都是同一个模子的标准件。从工程角度看可预测性比“美观”重要得多。代码风格这东西本质上没有绝对的对错如果工具能够消灭这个维度的讨论团队的沟通带宽就能省下来。2.2 核心格式化规则拆解Black默认使用 88 字符的行宽限制而不是 PEP 8 推荐的 79。这点很多刚开始用它的人会疑惑我当初也是。为什么是 88官方的解释很直白79 太窄了很容易导致不必要的换行88 是实测中阅读体验和换行频率之间的一个平衡点。而且 88 有个数学上的小彩蛋——它是 79 乘以 8/7 然后往上取整得到的。当然你不必记住这个由来只要知道它是默认值一般情况下不建议改。几个你一定会观察到的高频规则字符串引号统一如果代码里混用了单引号和双引号Black会把它们统一成双引号。但有个例外——如果字符串内部已经含有双引号它会根据“哪个引号能减少转义次数”来做选择。括号内的行尾逗号这个比较有意思。如果一组函数参数或列表元素在括号内是逐个拆行写的Black会在最后一个元素后面补一个逗号。这个“行尾逗号”是给未来的修改留的缝——下次你在末尾加一行时git diff 就不会把上一行也标记为修改。这是Black设计里很聪明的一个细节。大段可拆分表达式如果一行超长Black会优先在运算符处换行并且让运算符行首对齐。它不会把一个原子表达式比如一个很长的变量名硬拆开。空行处理模块级别的函数和类定义之间强制保留两个空行类内部的方法之间保留一个空行。多余的空行会被清理掉。拿一小段代码举例这是格式化前def calculate_discount(price: float, is_member: bool False, coupon_code: str None, quantity: int 1) - float: totalprice*quantity if is_member: total*0.9 if coupon_code SAVE20: total*0.8 return round(total, 2)运行black之后def calculate_discount( price: float, is_member: bool False, coupon_code: str None, quantity: int 1, ) - float: total price * quantity if is_member: total * 0.9 if coupon_code SAVE20: total * 0.8 return round(total, 2)注意几个变化两侧被补上了空格函数参数因为超过行宽被拆成每行一个并且末尾补了逗号return前保留了恰当的空行。这些改动没有一条改变代码语义但整体阅读成本显著降低。2.3 它和 PEP 8 的关系不是翻译是取舍很多人把Black简单理解成“自动执行 PEP 8 的工具”这个说法其实不准确。Black是基本遵循PEP 8但在不少地方刻意偏离。最典型的就是 88 字符行宽以及它对某些“竖排对齐”风格的放弃。PEP 8 里有种写法是把赋值语句的等号对齐比如name 张三 age 30 is_student FalseBlack碰到这种代码会直接把它改成name 张三 age 30 is_student False它认为这种“对齐”是徒劳的——一旦变量名长度变了整个块都要重新对齐而且这种格式差异在代码评审里毫无信息量。这种“反装饰性”的态度贯穿Black的整个设计。理解了这一层你就不会拿着Black格式化后的代码去对比 PEP 8 然后发出“这也不符合规范啊”的质疑了。Black有自己的规范这个规范比 PEP 8 更统一、更严格、更没有商量余地。3. 从安装到接入工作流编辑器、pre-commit、CI其实安装和基本使用非常简单我把整个接入过程分成三个层次你可以根据自己的项目规模选择。日常单机用、团队协作用、以及强制约束用配置强度完全不同。3.1 安装与基础命令安装就是一条命令的事pip install black如果是用poetry或者pipenv管理的项目加进开发依赖里poetry add --dev black基础用法非常直观直接指定文件或目录# 格式化单个文件 black my_script.py # 格式化整个目录递归 black src/ # 只检查但不修改 black --check src/ # 检查并输出差异 black --diff src/--check这个参数在 CI 里非常有用。它能确保不会有人往主分支提交未格式化的代码。--diff则是配合--check使用的CI 输出差异开发者看到后本地跑一遍即可。如果有人跑了black之后发现整个文件被改得面目全非多半是没注意到一个关键点Black从 22.0 版本开始默认就不支持 Python 2 了如果你维护的是 Python 2 项目需要加--target-version py27之类的参数。现在基本很少有人还在维护 Python 2我就不展开了。3.2 VS Code 和 PyCharm 里的配置方式编辑器集成是我觉得体验提升最明显的一环。VS Code 里装一个Black Formatter插件就是微软官方出的那个然后在设置里做两处调整{ editor.formatOnSave: true, python.formatting.provider: black }如果你用的是新版 VS Codepython.formatting.provider这个选项可能已经被移到扩展设置里了。直接安装扩展后按CtrlShiftP打开命令面板输入 Preferences: Open Settings (JSON)把上面两行写进配置。这样每次保存文件Black就会自动帮你重排一遍格式。PyCharm 用户稍微麻烦一点。PyCharm 是自带一套格式化器的要换成Black得走Settings - Tools - Black勾选 Run Black on save。如果找不到这个选项大概率是还没安装Black插件在插件市场搜一下装好重启再来看。提示我个人的建议是保存时自动格式化一定要开。你既然决定用Black就不要抱着“我先写得随意一点最后统一处理”的心态。你自己手动跑black的话由于产生大量格式变更会挤压掉同一次提交里真正的逻辑修改导致 Code Review 分不清重点。开了保存时格式化格式是渐变的diff 会清爽很多。3.3 pre-commit 钩子把卡口提前到提交阶段编辑器自动格式化管的是“自己写的代码”pre-commit 钩子管的是“即将进入版本库的代码”。即便团队有人没用编辑器插件或者用了但没有正确配置他提交代码的时候 pre-commit 也会拦住并自动修复。项目根目录新建.pre-commit-config.yamlrepos: - repo: https://github.com/psf/black rev: 24.2.0 hooks: - id: black language_version: python3.12然后安装钩子pip install pre-commit pre-commit install接下来每次git commitpre-commit 都会先跑一轮Black如果有文件格式不对钩子会自动改写文件并且取消本次提交。你检查一下改动重新git add和git commit就能过。language_version这个参数建议始终设置为团队实际使用的 Python 版本。否则 pre-commit 默认使用系统当前默认 Python可能因为版本不一致导致格式化结果不同。3.4 CI 层兜底Pull Request 强制检查pre-commit 属于“自觉型”约束理论上可以通过--no-verify跳过。所以真正的最后一道防线是 CI。GitHub Actions 里配一个非常简单的工作流name: format-check on: [push, pull_request] jobs: black: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - uses: actions/setup-pythonv5 with: python-version: 3.12 - run: pip install black - run: black --check .black --check .会扫描当前目录下所有.py文件只要有一个未格式化命令就返回非零退出码CI 就挂。这个配置的目的不在于惩罚谁而在于让“格式不合格”成为一个完全客观的事实而不是评审人一句可有可无的“建议格式化一下”。团队里推行Black的那段时间我的体感是头一两天大家会觉得改动很大需要适应新格式一周之后几乎所有人的注意力都自动回到了逻辑本身。因为风格问题在提交之前就已经被解决了评审里再也没有人提“这里要不要加个空格”之类的意见。省下来的精力是实打实的。4. 实战中躲不开的那些坑以及解决办法Black本身没什么学习曲线真正的坑都藏在“用了之后才遇到”的意外情况里。我在这里把常见的几个集中写出来每个都是我或者同事真实被绊过的。4.1 大改版导致的 git 历史混乱用 .git-blame-ignore-revs 保住追溯能力给既有项目启用Black第一次全量格式化是必经之路。但问题是格式化之后每个文件都会发生大量行变更。GitHub 上点开任意一行代码git blame显示的提交者可能都是“格式化代码”的这次提交而不是真正写这行逻辑的人。这对后续追查修改历史的效率是个不小的打击。解决办法是git blame的忽略机制。在仓库里放一个.git-blame-ignore-revs文件内容写那一次格式化提交的 SHA# 首次全量应用 Black 格式化 9f7d3a2b1c4e8a0d6f5b3a9c2e4d8f6a0b1c2d3e然后把项目配置成默认读取这个文件git config blame.ignoreRevsFile .git-blame-ignore-revsGitHub 也能识别。在仓库的.git-blame-ignore-revs文件里列出需要忽略的提交GitHub 的 blame 页面就不会把那笔提交算进“责任方”。这个操作建议在动手格式化之前就配置好不然格式化提交已经进历史了再找 SHA 也不算麻烦但毕竟多一步。4.2 魔法逗号Magic Trailing Comma影响多行结构前面提到Black会在拆分后的列表末尾补逗号这个特性本身很聪明但它有一个“副作用”末尾逗号会强制Black保持多行结构。看这个例子items [ apple, banana, orange, ]它最后一行有逗号Black会维持这种多行展开。但如果代码是items [apple, banana, orange]这一行没超过 88 字符Black就不动。可当你为了某个原因手动把三个元素拆成三行并且第三行末尾有逗号时即便这一行后来变短了、完全能在 88 字符内用单行装下Black依然会保持拆行——因为它认为末尾逗号是你的“明确意图”。这不是 bug是设计。很多人在第一次遇到的时候会困惑“为什么不给我合并成一行了”其实是忘了删末尾那个逗号。理解了它的用途鼓励增量修改时 diff 更干净你就知道什么时候该留什么时候该删了。4.3 行宽限制与字符串的冲突# fmt: off是最后手段默认 88 字符的规则很合理但实际项目中总有边界情况绕不过去。最常见的是本来格式化好的代码因为一个超长的 URL、或者一个不能拆分的正则表达式被Black强行换行结果看起来更难受。比如url ( https://api.example.com/v1/products?categoryelectronicssotr_byprice orderdesc )如果这是测试代码里的一个“期望完整 URL”拆成两行拼接虽然语义没变字符串字面量也会自动合并但直接复制这个 URL 的时候还是会被中间的空格干扰到。这种情况下有两个选择把整个字符串赋给一个变量Black对变量赋值不会强行改变字符串内容用# fmt: off和# fmt: on标记块让Black完全忽略这段代码。# fmt: off url https://api.example.com/v1/products?categoryelectronicssort_bypriceorderdesc # fmt: on# fmt: off是“最终解释权归开发者”的声明。但我的建议是这个用法要克制。如果一个文件里出现超过两处# fmt: off你就该反思是不是代码本身设计有问题而不是一味地把问题抛给格式工具。格式工具的职责边界恰好也是代码设计的预警线这是使用任何自动化工具时都值得记住的一点。4.4 混合中英文注释时的引号问题我们的项目里注释有中文有英文这是一个被同事踩过好多次的细节。Black默认情况下对注释里的引号不做任何处理但如果你写了三引号字符串比如文档字符串def process_data(df): 处理数据默认按时间排序。 参数: df: 输入的 DataFrame ...Black处理文档字符串时默认会把开头和结尾的三引号以及内部缩进重新规范。如果你在文档字符串里故意用了某种让说明文字保持精确缩进的排版跑完Black之后可能会看到缩进被调整。最稳妥的做法是文档字符串遵循统一规范书写不要在里面写需要“保持原样”的表格或代码块。如果确实需要保留复杂排版# fmt: off还是可以顶一下。4.5 和 Jupyter Notebook 的兼容问题现在不少人直接在.ipynb里写代码Black本身支持 notebook 作为输入但如果你用的是老版本或者直接对整个目录执行black .可能会遇到 notebook 相关的格式错误或警告。新版Black对 ipynb 支持已经很稳定会自动提取每个 cell 的代码部分做格式化然后再写回去不影响输出结果。唯一要注意的是notebook 格式化后通常会产生大量 cell 变更如果你在 Jupyter 里开着文件Black改了磁盘上的文件页面里可能不会实时刷新偶尔会提示“文件已更改”。所以推荐的处理方式是notebook 的格式化单独跑不要和.py文件混在一起并且进入格式化流程前先保存所有 cell。5. Black 和 isort、autopep8、yapf 的搭配才算完整Black解决的仅仅是“代码长什么样”的问题。还有一个常见的相邻问题它故意没有处理import 语句的顺序。Black的设计者是故意的——import 排序是一个有语义争议的话题他不愿意把排序方式也变成“独裁式”决定。所以现实中几乎必然出现这样的组合Blackisort。isort专门负责把 import 块整理成标准库、第三方库、本地模块三组每组内部按字母序排好。两个工具一起用import 和代码体格都有规矩。5.1 isort 必须开启 profileblack如果isort使用默认配置它的折行方式和Black会有冲突。举一个典型场景某个 import 语句在isort看来可以拆成两行但因为两者对括号后换行的处理逻辑不同可能你跑完isort再跑Black代码刚好被改成另一种格式反过来跑又不一样。两个工具互相打架这在团队里会产生灾难性的体验。解决办法是在pyproject.toml里给isort显式配置Black的兼容模式[tool.isort] profile black line_length 88profile black意味着isort内部所有折行逻辑都会遵循Black对括号和行长的规则减少冲突。这是isort官方为了配合Black专门提供的选项不是社区 hack。排序 import 和格式化代码顺序上我建议先跑isort再跑Black。因为isort改变的是行顺序可能产生一些新的折行需求之后再跑Black会把这些新行统一整理。5.2 为什么不推荐 autopep8 和 yapf 与 Black 混用autopep8的目标是用尽可能小的改动量把代码修成“符合 PEP 8”它不会像Black那样对代码做全局重构式的重排。而yapf恰恰相反它提供了极其丰富的配置项鼓励使用者“调出适合团队的风格”。Black和这两者的哲学本质上是冲突的Black认为不该有可配置的风格选项yapf则认为一切都是可配置的。硬把它们放一起用只会出现无限循环的互相覆盖。所以要么选Black要么选yapf不要同时上。市面上没有哪个知名项目是Black打底再叠加yapf的这本身就很说明问题。5.3 pre-commit 里 isort 和 Black 的顺序如果用了 pre-commit 钩子务必先跑isort再跑Black。配置可以这样写repos: - repo: https://github.com/PyCQA/isort rev: 5.13.2 hooks: - id: isort args: [--profile, black] - repo: https://github.com/psf/black rev: 24.2.0 hooks: - id: black language_version: python3.12isort执行后Black会在它基础上做最终排版。这个顺序保持明确才能确保两个工具不会互相破坏结果。5.4 测试文件和一些特殊目录的节奏从实际项目出发我给个建议tests目录里的代码最好也格式化但类名和函数名比较长的测试代码经常会触发Black的折行逻辑导致断言一长串被拆得乱糟糟的。如果你发现测试代码被拆得可读性反而下降可以在测试目录单独跑Black时加--skip-magic-trailing-comma参数这个参数在新版中仍然保留能关闭魔法逗号带来的强制拆行行为。不过这是治标不治本。我个人的做法是宁可让测试代码多换几行也不要动不动就对某一部分关闭格式化否则 review 的时候容易混淆规范边界。6. 自定义的边界几行配置能做和不能做的事Black说自己“不妥协”但它还是留下了少数几个配置项。全部集中在pyproject.toml里这也是Black的现代推荐配置方式。6.1 最常用的三个配置项项目根目录的pyproject.toml里可以写[tool.black] line-length 100 target-version [py311, py312] include \.pyi?$ extend-exclude /(\.venv|venv|build|dist|migrations)/ line-length全局调整行宽。有的项目坚信用 100有的想保留 120。改是可以改但我的态度是除非有非常强的理由否则就用默认 88。因为社区插件、文档、其他工具的默认值都围绕 88 展开改大之后某些依赖Black风格假设的工具比如isort profile的匹配也要一起调徒增维护成本。target-version指定项目要兼容的 Python 版本。Black在格式化时会根据目标版本决定是否使用一些新的语法结构。如果你的项目有最低 Python 版本要求这个字段一定要设置准确。include/extend-exclude控制Black扫描哪些文件。默认会递归扫描但venv、.venv、build、dist这些目录建议提前排除不然每次跑都会做一堆无用功。注意extend-exclude是正则表达式路径是相对当前目录的。6.2 语法风格的版本演进升级要谨慎Black版本升级有时候会带来格式化结果的变化。虽然它尽量保持稳定但每代版本在边缘情况上会修正一些判断比如 23 年的版本对某些嵌套括号的拆分逻辑做了调整24 年的稳定版对hug_parens_with_braces风格做了实验性支持。如果你在团队中已经锁定了某个Black版本不要逢升级就跟着升。升级前先在本地对全项目跑一遍black --diff确认格式差异是否可控再决定是否统一升级。提示把Black固定在某个精确版本比如black24.2.0是规避团队间格式化结果不一致的有效手段。只要版本不同哪怕主版本号相同格式化结果都可能出现差异。6.3 它刻意不做的事为什么这么设计试过一段时间Black之后你会陆续发现有些它“不帮你做”的事。这些“不做”不是能力不足是设计边界。它不会帮你排序 import前面说了这是isort的活它不会把一行很长的函数调用自动折叠成多行只是会拆线它不会重命名变量更不会修复类型错误。它只做词法和语法层面的排版不深入到 AST 之上的语义层面。这个边界其实非常合理。代码格式化工具如果管得太宽——比如自动把 None改成is None虽然看似贴心但一旦误判就会改变程序行为。Black坚持“绝不改变语义”这个底线在自动化工具里是极其重要的可信度保障。你看到一段Black处理过的代码可以放心地对它说一句它只是换了身衣服内心没有变。这种确定性恰恰是它能在 CI 里担当“硬门槛”的原因。7. 按规模选接入姿势单人多仓、团队新项目、存量老项目三种形态前面配置都讲完了最后根据项目规模聊聊我实际推荐的接入方式。不同体量的项目接入Black的平滑度差别很大。7.1 单人维护的小工具库如果你有一个自己长期维护的库哪怕只有二三十个文件也值得上Black。这个阶段接入成本最低因为没人跟你争。同时你会养成“保存即格式化”的习惯写代码时不再潜意识地纠结“要不要在这里换行”心理负担会显著减少。配置的话pyproject.toml里加[tool.black]然后日常命令就是black .。如果你用的是 VS Code把保存时格式化打开基本上跑命令只需要在 CI 里出现。7.2 团队新项目从第一天就强制新项目没有历史包袱最佳实践就是从一开始就把Black锁进工具链。脚手架阶段就把 pre-commit、CI 一起配好。这一阶段要注意的是约定版本。团队里统一安装指定版本的Black建议用requirements-dev.txt或poetry的开发依赖锁定避免有人环境里是 23 年的版本有人是 24 年的处理同样的代码得出不同结果然后互相怀疑。新项目代码量小CI 跑一次black --check .基本在毫秒到秒级没有任何性能负担。7.3 存量老项目分模块渐进别一把梭存量项目最忌讳的是“在某个周五下午全仓格式化然后让你自己处理上百个文件的冲突”。合理的做法是分模块推进。比如这个月格式化了auth/和user/两个目录下个月再处理billing/。pyproject.toml里可以用include限定本次格式化的范围[tool.black] include (auth|user)/.*\.py$每次格式化一个模块紧接着做一轮细致的回归验证再提交代码。这样即使出现意外问题也被限制在可控范围内。我一直强调的.git-blame-ignore-revs在存量项目里是绝对必要的务必在第一次格式化之前就配置好。我们当时吃过亏全仓格式化后一个老功能出了 bug大家靠git log找改动来源发现整页都是同一个格式化 commit那次排查比想象中花了更久。后来配好 ignore 文件这条隐患才真正消除。7.4 格式化后的代码要不要“人工校对”跑完Black之后我的习惯是随机抽几个关键文件看一眼 diff不是逐行检查而是确认它没有把我的结构弄坏。虽然Black承诺不改变语义但它对括号的拆分和重组偶尔会暴露代码本身的问题——比如本意想包在某个作用域里的代码因为括号配对错位而执行顺序不对。这种问题不是Black造成的但它会把你以前“歪打正着能跑”的事情翻出来。换句话说Black不仅是格式化工具它还能当“健康检查工具”用。当你把代码交到它手里它反哺给你的不仅是统一格式还有一次额外的审视机会。8. 最后再分享几个实战心得Black用了这几年有几件小事是文档里不太会详细写、但实际体验影响很大的。第一个是终端命令的技巧。日常使用中我最常跑的组合是black --check --diff .它只输出会变化的差异不实际修改文件用于快速预览改动范围。如果要提交前统一处理再跑black .。这个习惯能避免一个很尴尬的情况你写了两百行新代码一提交被 CI 拦截然后 CI 日志里black --check显示的改法和你本地预期不一致。第二个是关于# fmt: off的使用场景。我见过的合理场景大多是表格型数据。比如一个映射表键和值的长度差距很大按Black的默认规则会被拆成好多行读起来反而不如紧凑排列的表格清晰。这时候用# fmt: off保留手写排版是合理的人类判断。# fmt: off STATUS_MESSAGES { 200: OK, 201: Created, 204: No Content, 400: Bad Request, 401: Unauthorized, 404: Not Found, } # fmt: on如果不用# fmt: offBlack大概率会保留字典的值在同一行但键和值不对齐这其实是可接受的。所以到底要不要用还是要看排版是否真的影响阅读。第三个是关于格式化与代码评审顺序。我强烈建议在评审中区分“格式化提交”和“逻辑提交”。如果某次改动里既有大量格式变更又有逻辑变化评审人很难看出重点。在我现在的团队流程里Black相关的改动永远单独成一个 commit标题就写style: apply black和功能变更完全隔离。这个习惯一旦养成代码回滚和定位 bug 的效率都会明显提升。第四个经验是关于Black的版本选择和升级节奏。我在多个项目里验证过把Black固定在稳定版并跟随小版本升级是性价比最高的做法。如果Black出了新的大版本不要急着升级先在本地跑一遍black --diff .看看它对你的代码库究竟改了多少内容。如果差异巨大说明它的格式化策略有调整这时要谨慎。如果差异很小那升级无妨。我把这个流程称为“格式化工具的先行验收”非常简单但能避免很多无意义的冲突。如果你打算在团队里引入Black我的建议很简单不要开座谈会讨论“团队需要什么风格”直接规定“我们用Black”。风格问题不适合民主表决适合直接裁决。这句话听起来有点绝对但在我合作过的所有团队里最终发现大家真正想要的只是“快点结束风格讨论去写业务代码”——Black恰好能给你这个。
Python代码格式化工具Black实战：从原理到团队协作配置
1. 为什么风格统一这件事比你想的更值钱先聊个我真实见过的场景。几年前我们团队接了个维护项目代码库年龄大概四岁前后经过七八个人的手。有人用四个空格有人用 Tab有人喜欢把函数参数一个挨一个地写在两行里还有人喜欢把整个 if 分支都挤成一行。每次做 Code Review最耗精力的不是业务逻辑而是大家在评论区里为了“这个缩进到底算不算对齐”来回讨论。你改我的格式我改你的格式最后 git 历史里多了几十个除了换行没有任何实际变更的提交。后来我和一个从大厂出来的同事聊起这个问题他说他们那边从某一天起强制上了Black约定俗成谁提交的代码不符合统一格式CI 直接红。团队里没有人再花时间讨论风格因为没得讨论。那个瞬间我才意识到代码格式化工具解决的根本不是“美丑”问题它解决的是协作成本问题。Python 社区里格式化工具其实不少autopep8、yapf、Black各有拥趸。但Black的定位和它们完全不同。它不是“帮你把代码改得符合 PEP 8 的建议”而是“直接剥夺你选择风格的权力”。用官方的话说它是一个uncompromising code formatter——不妥协、不让步。你给它一段 Python 代码它吐出一段格式完全确定的代码同样的输入永远得到同样的输出不管谁在什么机器上跑结果都一样。如果你一个人写独立项目说实话加不加格式化工具都无所谓反正代码只有你自己看。但只要是两人以上的协作或者你想让自己三个月后回看代码时少花点力气Black这种“独裁式”的格式化思路反而是最大的公平。它不看资历不看个人偏好不搞“我觉得这样读起来更顺”所有争议在工具层面就终结了。这篇文章就从原理、配置、踩坑、和其它工具搭配这几个维度把Black讲透。不是抄官方文档而是把我在真实项目里跑的细节、遇到的意外情况、以及最终沉淀下来的工作流都写出来。2. Black 到底按什么规则替你写代码先不急着配置搞清楚Black的内部逻辑会让你使用起来顺手得多。不然你会遇到一种很常见的困惑为什么我这段代码被它改成了这样为什么那行它就不动2.1 最核心的设计哲学结果必须可预测Black的设计者有个非常硬核的理念所有风格决策都应该由工具决定而不是由开发者决定。它不允许你通过配置文件去调整“缩进用几个空格”这类参数也不提供“左花括号要不要换行”的选项。市面上大部分格式化工具提供的是建议Black提供的是裁决。这个哲学带来一个直接结果团队成员之间不需要建立“我们约定好了超过 79 个字符就手动换行”这种口头契约。因为只要有人某个地方忘了遵守Black一跑就全给你收拾整齐。相比之下autopep8更像是一个温和的老师它指出你哪里不符合规范能改的顺手帮你改而Black是一台流水线机器无论什么样的毛坯件进去出来的都是同一个模子的标准件。从工程角度看可预测性比“美观”重要得多。代码风格这东西本质上没有绝对的对错如果工具能够消灭这个维度的讨论团队的沟通带宽就能省下来。2.2 核心格式化规则拆解Black默认使用 88 字符的行宽限制而不是 PEP 8 推荐的 79。这点很多刚开始用它的人会疑惑我当初也是。为什么是 88官方的解释很直白79 太窄了很容易导致不必要的换行88 是实测中阅读体验和换行频率之间的一个平衡点。而且 88 有个数学上的小彩蛋——它是 79 乘以 8/7 然后往上取整得到的。当然你不必记住这个由来只要知道它是默认值一般情况下不建议改。几个你一定会观察到的高频规则字符串引号统一如果代码里混用了单引号和双引号Black会把它们统一成双引号。但有个例外——如果字符串内部已经含有双引号它会根据“哪个引号能减少转义次数”来做选择。括号内的行尾逗号这个比较有意思。如果一组函数参数或列表元素在括号内是逐个拆行写的Black会在最后一个元素后面补一个逗号。这个“行尾逗号”是给未来的修改留的缝——下次你在末尾加一行时git diff 就不会把上一行也标记为修改。这是Black设计里很聪明的一个细节。大段可拆分表达式如果一行超长Black会优先在运算符处换行并且让运算符行首对齐。它不会把一个原子表达式比如一个很长的变量名硬拆开。空行处理模块级别的函数和类定义之间强制保留两个空行类内部的方法之间保留一个空行。多余的空行会被清理掉。拿一小段代码举例这是格式化前def calculate_discount(price: float, is_member: bool False, coupon_code: str None, quantity: int 1) - float: totalprice*quantity if is_member: total*0.9 if coupon_code SAVE20: total*0.8 return round(total, 2)运行black之后def calculate_discount( price: float, is_member: bool False, coupon_code: str None, quantity: int 1, ) - float: total price * quantity if is_member: total * 0.9 if coupon_code SAVE20: total * 0.8 return round(total, 2)注意几个变化两侧被补上了空格函数参数因为超过行宽被拆成每行一个并且末尾补了逗号return前保留了恰当的空行。这些改动没有一条改变代码语义但整体阅读成本显著降低。2.3 它和 PEP 8 的关系不是翻译是取舍很多人把Black简单理解成“自动执行 PEP 8 的工具”这个说法其实不准确。Black是基本遵循PEP 8但在不少地方刻意偏离。最典型的就是 88 字符行宽以及它对某些“竖排对齐”风格的放弃。PEP 8 里有种写法是把赋值语句的等号对齐比如name 张三 age 30 is_student FalseBlack碰到这种代码会直接把它改成name 张三 age 30 is_student False它认为这种“对齐”是徒劳的——一旦变量名长度变了整个块都要重新对齐而且这种格式差异在代码评审里毫无信息量。这种“反装饰性”的态度贯穿Black的整个设计。理解了这一层你就不会拿着Black格式化后的代码去对比 PEP 8 然后发出“这也不符合规范啊”的质疑了。Black有自己的规范这个规范比 PEP 8 更统一、更严格、更没有商量余地。3. 从安装到接入工作流编辑器、pre-commit、CI其实安装和基本使用非常简单我把整个接入过程分成三个层次你可以根据自己的项目规模选择。日常单机用、团队协作用、以及强制约束用配置强度完全不同。3.1 安装与基础命令安装就是一条命令的事pip install black如果是用poetry或者pipenv管理的项目加进开发依赖里poetry add --dev black基础用法非常直观直接指定文件或目录# 格式化单个文件 black my_script.py # 格式化整个目录递归 black src/ # 只检查但不修改 black --check src/ # 检查并输出差异 black --diff src/--check这个参数在 CI 里非常有用。它能确保不会有人往主分支提交未格式化的代码。--diff则是配合--check使用的CI 输出差异开发者看到后本地跑一遍即可。如果有人跑了black之后发现整个文件被改得面目全非多半是没注意到一个关键点Black从 22.0 版本开始默认就不支持 Python 2 了如果你维护的是 Python 2 项目需要加--target-version py27之类的参数。现在基本很少有人还在维护 Python 2我就不展开了。3.2 VS Code 和 PyCharm 里的配置方式编辑器集成是我觉得体验提升最明显的一环。VS Code 里装一个Black Formatter插件就是微软官方出的那个然后在设置里做两处调整{ editor.formatOnSave: true, python.formatting.provider: black }如果你用的是新版 VS Codepython.formatting.provider这个选项可能已经被移到扩展设置里了。直接安装扩展后按CtrlShiftP打开命令面板输入 Preferences: Open Settings (JSON)把上面两行写进配置。这样每次保存文件Black就会自动帮你重排一遍格式。PyCharm 用户稍微麻烦一点。PyCharm 是自带一套格式化器的要换成Black得走Settings - Tools - Black勾选 Run Black on save。如果找不到这个选项大概率是还没安装Black插件在插件市场搜一下装好重启再来看。提示我个人的建议是保存时自动格式化一定要开。你既然决定用Black就不要抱着“我先写得随意一点最后统一处理”的心态。你自己手动跑black的话由于产生大量格式变更会挤压掉同一次提交里真正的逻辑修改导致 Code Review 分不清重点。开了保存时格式化格式是渐变的diff 会清爽很多。3.3 pre-commit 钩子把卡口提前到提交阶段编辑器自动格式化管的是“自己写的代码”pre-commit 钩子管的是“即将进入版本库的代码”。即便团队有人没用编辑器插件或者用了但没有正确配置他提交代码的时候 pre-commit 也会拦住并自动修复。项目根目录新建.pre-commit-config.yamlrepos: - repo: https://github.com/psf/black rev: 24.2.0 hooks: - id: black language_version: python3.12然后安装钩子pip install pre-commit pre-commit install接下来每次git commitpre-commit 都会先跑一轮Black如果有文件格式不对钩子会自动改写文件并且取消本次提交。你检查一下改动重新git add和git commit就能过。language_version这个参数建议始终设置为团队实际使用的 Python 版本。否则 pre-commit 默认使用系统当前默认 Python可能因为版本不一致导致格式化结果不同。3.4 CI 层兜底Pull Request 强制检查pre-commit 属于“自觉型”约束理论上可以通过--no-verify跳过。所以真正的最后一道防线是 CI。GitHub Actions 里配一个非常简单的工作流name: format-check on: [push, pull_request] jobs: black: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - uses: actions/setup-pythonv5 with: python-version: 3.12 - run: pip install black - run: black --check .black --check .会扫描当前目录下所有.py文件只要有一个未格式化命令就返回非零退出码CI 就挂。这个配置的目的不在于惩罚谁而在于让“格式不合格”成为一个完全客观的事实而不是评审人一句可有可无的“建议格式化一下”。团队里推行Black的那段时间我的体感是头一两天大家会觉得改动很大需要适应新格式一周之后几乎所有人的注意力都自动回到了逻辑本身。因为风格问题在提交之前就已经被解决了评审里再也没有人提“这里要不要加个空格”之类的意见。省下来的精力是实打实的。4. 实战中躲不开的那些坑以及解决办法Black本身没什么学习曲线真正的坑都藏在“用了之后才遇到”的意外情况里。我在这里把常见的几个集中写出来每个都是我或者同事真实被绊过的。4.1 大改版导致的 git 历史混乱用 .git-blame-ignore-revs 保住追溯能力给既有项目启用Black第一次全量格式化是必经之路。但问题是格式化之后每个文件都会发生大量行变更。GitHub 上点开任意一行代码git blame显示的提交者可能都是“格式化代码”的这次提交而不是真正写这行逻辑的人。这对后续追查修改历史的效率是个不小的打击。解决办法是git blame的忽略机制。在仓库里放一个.git-blame-ignore-revs文件内容写那一次格式化提交的 SHA# 首次全量应用 Black 格式化 9f7d3a2b1c4e8a0d6f5b3a9c2e4d8f6a0b1c2d3e然后把项目配置成默认读取这个文件git config blame.ignoreRevsFile .git-blame-ignore-revsGitHub 也能识别。在仓库的.git-blame-ignore-revs文件里列出需要忽略的提交GitHub 的 blame 页面就不会把那笔提交算进“责任方”。这个操作建议在动手格式化之前就配置好不然格式化提交已经进历史了再找 SHA 也不算麻烦但毕竟多一步。4.2 魔法逗号Magic Trailing Comma影响多行结构前面提到Black会在拆分后的列表末尾补逗号这个特性本身很聪明但它有一个“副作用”末尾逗号会强制Black保持多行结构。看这个例子items [ apple, banana, orange, ]它最后一行有逗号Black会维持这种多行展开。但如果代码是items [apple, banana, orange]这一行没超过 88 字符Black就不动。可当你为了某个原因手动把三个元素拆成三行并且第三行末尾有逗号时即便这一行后来变短了、完全能在 88 字符内用单行装下Black依然会保持拆行——因为它认为末尾逗号是你的“明确意图”。这不是 bug是设计。很多人在第一次遇到的时候会困惑“为什么不给我合并成一行了”其实是忘了删末尾那个逗号。理解了它的用途鼓励增量修改时 diff 更干净你就知道什么时候该留什么时候该删了。4.3 行宽限制与字符串的冲突# fmt: off是最后手段默认 88 字符的规则很合理但实际项目中总有边界情况绕不过去。最常见的是本来格式化好的代码因为一个超长的 URL、或者一个不能拆分的正则表达式被Black强行换行结果看起来更难受。比如url ( https://api.example.com/v1/products?categoryelectronicssotr_byprice orderdesc )如果这是测试代码里的一个“期望完整 URL”拆成两行拼接虽然语义没变字符串字面量也会自动合并但直接复制这个 URL 的时候还是会被中间的空格干扰到。这种情况下有两个选择把整个字符串赋给一个变量Black对变量赋值不会强行改变字符串内容用# fmt: off和# fmt: on标记块让Black完全忽略这段代码。# fmt: off url https://api.example.com/v1/products?categoryelectronicssort_bypriceorderdesc # fmt: on# fmt: off是“最终解释权归开发者”的声明。但我的建议是这个用法要克制。如果一个文件里出现超过两处# fmt: off你就该反思是不是代码本身设计有问题而不是一味地把问题抛给格式工具。格式工具的职责边界恰好也是代码设计的预警线这是使用任何自动化工具时都值得记住的一点。4.4 混合中英文注释时的引号问题我们的项目里注释有中文有英文这是一个被同事踩过好多次的细节。Black默认情况下对注释里的引号不做任何处理但如果你写了三引号字符串比如文档字符串def process_data(df): 处理数据默认按时间排序。 参数: df: 输入的 DataFrame ...Black处理文档字符串时默认会把开头和结尾的三引号以及内部缩进重新规范。如果你在文档字符串里故意用了某种让说明文字保持精确缩进的排版跑完Black之后可能会看到缩进被调整。最稳妥的做法是文档字符串遵循统一规范书写不要在里面写需要“保持原样”的表格或代码块。如果确实需要保留复杂排版# fmt: off还是可以顶一下。4.5 和 Jupyter Notebook 的兼容问题现在不少人直接在.ipynb里写代码Black本身支持 notebook 作为输入但如果你用的是老版本或者直接对整个目录执行black .可能会遇到 notebook 相关的格式错误或警告。新版Black对 ipynb 支持已经很稳定会自动提取每个 cell 的代码部分做格式化然后再写回去不影响输出结果。唯一要注意的是notebook 格式化后通常会产生大量 cell 变更如果你在 Jupyter 里开着文件Black改了磁盘上的文件页面里可能不会实时刷新偶尔会提示“文件已更改”。所以推荐的处理方式是notebook 的格式化单独跑不要和.py文件混在一起并且进入格式化流程前先保存所有 cell。5. Black 和 isort、autopep8、yapf 的搭配才算完整Black解决的仅仅是“代码长什么样”的问题。还有一个常见的相邻问题它故意没有处理import 语句的顺序。Black的设计者是故意的——import 排序是一个有语义争议的话题他不愿意把排序方式也变成“独裁式”决定。所以现实中几乎必然出现这样的组合Blackisort。isort专门负责把 import 块整理成标准库、第三方库、本地模块三组每组内部按字母序排好。两个工具一起用import 和代码体格都有规矩。5.1 isort 必须开启 profileblack如果isort使用默认配置它的折行方式和Black会有冲突。举一个典型场景某个 import 语句在isort看来可以拆成两行但因为两者对括号后换行的处理逻辑不同可能你跑完isort再跑Black代码刚好被改成另一种格式反过来跑又不一样。两个工具互相打架这在团队里会产生灾难性的体验。解决办法是在pyproject.toml里给isort显式配置Black的兼容模式[tool.isort] profile black line_length 88profile black意味着isort内部所有折行逻辑都会遵循Black对括号和行长的规则减少冲突。这是isort官方为了配合Black专门提供的选项不是社区 hack。排序 import 和格式化代码顺序上我建议先跑isort再跑Black。因为isort改变的是行顺序可能产生一些新的折行需求之后再跑Black会把这些新行统一整理。5.2 为什么不推荐 autopep8 和 yapf 与 Black 混用autopep8的目标是用尽可能小的改动量把代码修成“符合 PEP 8”它不会像Black那样对代码做全局重构式的重排。而yapf恰恰相反它提供了极其丰富的配置项鼓励使用者“调出适合团队的风格”。Black和这两者的哲学本质上是冲突的Black认为不该有可配置的风格选项yapf则认为一切都是可配置的。硬把它们放一起用只会出现无限循环的互相覆盖。所以要么选Black要么选yapf不要同时上。市面上没有哪个知名项目是Black打底再叠加yapf的这本身就很说明问题。5.3 pre-commit 里 isort 和 Black 的顺序如果用了 pre-commit 钩子务必先跑isort再跑Black。配置可以这样写repos: - repo: https://github.com/PyCQA/isort rev: 5.13.2 hooks: - id: isort args: [--profile, black] - repo: https://github.com/psf/black rev: 24.2.0 hooks: - id: black language_version: python3.12isort执行后Black会在它基础上做最终排版。这个顺序保持明确才能确保两个工具不会互相破坏结果。5.4 测试文件和一些特殊目录的节奏从实际项目出发我给个建议tests目录里的代码最好也格式化但类名和函数名比较长的测试代码经常会触发Black的折行逻辑导致断言一长串被拆得乱糟糟的。如果你发现测试代码被拆得可读性反而下降可以在测试目录单独跑Black时加--skip-magic-trailing-comma参数这个参数在新版中仍然保留能关闭魔法逗号带来的强制拆行行为。不过这是治标不治本。我个人的做法是宁可让测试代码多换几行也不要动不动就对某一部分关闭格式化否则 review 的时候容易混淆规范边界。6. 自定义的边界几行配置能做和不能做的事Black说自己“不妥协”但它还是留下了少数几个配置项。全部集中在pyproject.toml里这也是Black的现代推荐配置方式。6.1 最常用的三个配置项项目根目录的pyproject.toml里可以写[tool.black] line-length 100 target-version [py311, py312] include \.pyi?$ extend-exclude /(\.venv|venv|build|dist|migrations)/ line-length全局调整行宽。有的项目坚信用 100有的想保留 120。改是可以改但我的态度是除非有非常强的理由否则就用默认 88。因为社区插件、文档、其他工具的默认值都围绕 88 展开改大之后某些依赖Black风格假设的工具比如isort profile的匹配也要一起调徒增维护成本。target-version指定项目要兼容的 Python 版本。Black在格式化时会根据目标版本决定是否使用一些新的语法结构。如果你的项目有最低 Python 版本要求这个字段一定要设置准确。include/extend-exclude控制Black扫描哪些文件。默认会递归扫描但venv、.venv、build、dist这些目录建议提前排除不然每次跑都会做一堆无用功。注意extend-exclude是正则表达式路径是相对当前目录的。6.2 语法风格的版本演进升级要谨慎Black版本升级有时候会带来格式化结果的变化。虽然它尽量保持稳定但每代版本在边缘情况上会修正一些判断比如 23 年的版本对某些嵌套括号的拆分逻辑做了调整24 年的稳定版对hug_parens_with_braces风格做了实验性支持。如果你在团队中已经锁定了某个Black版本不要逢升级就跟着升。升级前先在本地对全项目跑一遍black --diff确认格式差异是否可控再决定是否统一升级。提示把Black固定在某个精确版本比如black24.2.0是规避团队间格式化结果不一致的有效手段。只要版本不同哪怕主版本号相同格式化结果都可能出现差异。6.3 它刻意不做的事为什么这么设计试过一段时间Black之后你会陆续发现有些它“不帮你做”的事。这些“不做”不是能力不足是设计边界。它不会帮你排序 import前面说了这是isort的活它不会把一行很长的函数调用自动折叠成多行只是会拆线它不会重命名变量更不会修复类型错误。它只做词法和语法层面的排版不深入到 AST 之上的语义层面。这个边界其实非常合理。代码格式化工具如果管得太宽——比如自动把 None改成is None虽然看似贴心但一旦误判就会改变程序行为。Black坚持“绝不改变语义”这个底线在自动化工具里是极其重要的可信度保障。你看到一段Black处理过的代码可以放心地对它说一句它只是换了身衣服内心没有变。这种确定性恰恰是它能在 CI 里担当“硬门槛”的原因。7. 按规模选接入姿势单人多仓、团队新项目、存量老项目三种形态前面配置都讲完了最后根据项目规模聊聊我实际推荐的接入方式。不同体量的项目接入Black的平滑度差别很大。7.1 单人维护的小工具库如果你有一个自己长期维护的库哪怕只有二三十个文件也值得上Black。这个阶段接入成本最低因为没人跟你争。同时你会养成“保存即格式化”的习惯写代码时不再潜意识地纠结“要不要在这里换行”心理负担会显著减少。配置的话pyproject.toml里加[tool.black]然后日常命令就是black .。如果你用的是 VS Code把保存时格式化打开基本上跑命令只需要在 CI 里出现。7.2 团队新项目从第一天就强制新项目没有历史包袱最佳实践就是从一开始就把Black锁进工具链。脚手架阶段就把 pre-commit、CI 一起配好。这一阶段要注意的是约定版本。团队里统一安装指定版本的Black建议用requirements-dev.txt或poetry的开发依赖锁定避免有人环境里是 23 年的版本有人是 24 年的处理同样的代码得出不同结果然后互相怀疑。新项目代码量小CI 跑一次black --check .基本在毫秒到秒级没有任何性能负担。7.3 存量老项目分模块渐进别一把梭存量项目最忌讳的是“在某个周五下午全仓格式化然后让你自己处理上百个文件的冲突”。合理的做法是分模块推进。比如这个月格式化了auth/和user/两个目录下个月再处理billing/。pyproject.toml里可以用include限定本次格式化的范围[tool.black] include (auth|user)/.*\.py$每次格式化一个模块紧接着做一轮细致的回归验证再提交代码。这样即使出现意外问题也被限制在可控范围内。我一直强调的.git-blame-ignore-revs在存量项目里是绝对必要的务必在第一次格式化之前就配置好。我们当时吃过亏全仓格式化后一个老功能出了 bug大家靠git log找改动来源发现整页都是同一个格式化 commit那次排查比想象中花了更久。后来配好 ignore 文件这条隐患才真正消除。7.4 格式化后的代码要不要“人工校对”跑完Black之后我的习惯是随机抽几个关键文件看一眼 diff不是逐行检查而是确认它没有把我的结构弄坏。虽然Black承诺不改变语义但它对括号的拆分和重组偶尔会暴露代码本身的问题——比如本意想包在某个作用域里的代码因为括号配对错位而执行顺序不对。这种问题不是Black造成的但它会把你以前“歪打正着能跑”的事情翻出来。换句话说Black不仅是格式化工具它还能当“健康检查工具”用。当你把代码交到它手里它反哺给你的不仅是统一格式还有一次额外的审视机会。8. 最后再分享几个实战心得Black用了这几年有几件小事是文档里不太会详细写、但实际体验影响很大的。第一个是终端命令的技巧。日常使用中我最常跑的组合是black --check --diff .它只输出会变化的差异不实际修改文件用于快速预览改动范围。如果要提交前统一处理再跑black .。这个习惯能避免一个很尴尬的情况你写了两百行新代码一提交被 CI 拦截然后 CI 日志里black --check显示的改法和你本地预期不一致。第二个是关于# fmt: off的使用场景。我见过的合理场景大多是表格型数据。比如一个映射表键和值的长度差距很大按Black的默认规则会被拆成好多行读起来反而不如紧凑排列的表格清晰。这时候用# fmt: off保留手写排版是合理的人类判断。# fmt: off STATUS_MESSAGES { 200: OK, 201: Created, 204: No Content, 400: Bad Request, 401: Unauthorized, 404: Not Found, } # fmt: on如果不用# fmt: offBlack大概率会保留字典的值在同一行但键和值不对齐这其实是可接受的。所以到底要不要用还是要看排版是否真的影响阅读。第三个是关于格式化与代码评审顺序。我强烈建议在评审中区分“格式化提交”和“逻辑提交”。如果某次改动里既有大量格式变更又有逻辑变化评审人很难看出重点。在我现在的团队流程里Black相关的改动永远单独成一个 commit标题就写style: apply black和功能变更完全隔离。这个习惯一旦养成代码回滚和定位 bug 的效率都会明显提升。第四个经验是关于Black的版本选择和升级节奏。我在多个项目里验证过把Black固定在稳定版并跟随小版本升级是性价比最高的做法。如果Black出了新的大版本不要急着升级先在本地跑一遍black --diff .看看它对你的代码库究竟改了多少内容。如果差异巨大说明它的格式化策略有调整这时要谨慎。如果差异很小那升级无妨。我把这个流程称为“格式化工具的先行验收”非常简单但能避免很多无意义的冲突。如果你打算在团队里引入Black我的建议很简单不要开座谈会讨论“团队需要什么风格”直接规定“我们用Black”。风格问题不适合民主表决适合直接裁决。这句话听起来有点绝对但在我合作过的所有团队里最终发现大家真正想要的只是“快点结束风格讨论去写业务代码”——Black恰好能给你这个。
