1. 為什么你的Python代碼需要一臺“格式保險”先說個經(jīng)常在代碼評審里出現(xiàn)的名場面兩個人同時改一個文件一個人習(xí)慣雙引號一個人用單引號一個人喜歡把函數(shù)參數(shù)一行排完另一個人堅持每個參數(shù)獨立一行。結(jié)果review里一半以上都是“這里格式換一下”“那里 typo 順手改了”之類的噪音真正的邏輯問題反而被淹沒。我見過有的團隊為了這個專門在代碼規(guī)范文檔里寫三頁規(guī)則但執(zhí)行效果基本靠自覺——新成員加入后三周風(fēng)格就開始回到他上一家公司的習(xí)慣。Python本來就是一門強調(diào)可讀性的語言代碼格式這種“最不需要智力成本”的事情如果還在靠人肉提醒那說明工具鏈沒跟上。Black 就是來解決這個問題的。它是目前 Python 社區(qū)最流行的自動格式化工具之一核心邏輯直白得近乎粗暴它就是一臺“格式打印機”你用任何風(fēng)格寫它都用一套算法把你的代碼重新編排成它的輸出格式。換句話說你不需要記住“運算符兩側(cè)要空一格”“參數(shù)列表超過多少字符要換行”這類細節(jié)只要提交前跑一次black所有代碼會被統(tǒng)一成同一種樣式。它不跟你商量也不提供幾十個配置開關(guān)供你糾結(jié)所以也被戲稱為“專制的、不容爭辯的代碼格式化器”。這篇文章不是 Black 的官方文檔翻譯而是一個用過它、踩過坑、也用它解決過團隊鬧劇的人的經(jīng)驗總結(jié)。我會從核心規(guī)則講起然后是安裝配置、編輯器集成、CI落地最后把這幾年遇到過的坑一次性列出來。如果你準備在項目里引入 Black或者已經(jīng)被代碼格式問題煩得不行這篇值得你從頭看到尾。2. Black 的設(shè)計哲學(xué)與核心規(guī)則拆解2.1 它憑什么敢“專制”隨便搜一下 Black 的爭議你會看到兩派人。一派覺得它剝奪了“代碼美感”強行把所有代碼扭成一種形狀連某些字符串換行的風(fēng)格都要管另一派覺得它簡直救星從此再也不用參加“格式攻防戰(zhàn)”。Black 的作者 Lukas 說過一個很出名的觀點格式爭論是時間黑洞與其讓每個人自由發(fā)揮不如讓一個不可爭辯的格式化器拍板大家把精力留給邏輯。這個思路本質(zhì)上類似夫妻倆誰管錢——如果每次買菜都辯論“哪家的菜更值”日子沒法過不如定個規(guī)則那個價位下隨便哪家買了就走。Black 給你的是“無情緒”的確定性同一份代碼無論誰在什么機器上跑輸出都是逐字節(jié)相同版本鎖定的前提下。因此“代碼風(fēng)格是否好看”這個主觀問題被轉(zhuǎn)換成“是否遵守了 Black 輸出”的客觀判斷。代碼審查里不再有“我覺得這樣好看”的評論只有“跑一下 black”的提醒。從技術(shù)層面看Black 先把源碼解析成抽象語法樹AST再基于這個 AST 重新生成帶格式的代碼。這意味著它懂 Python 語法不會把合法的代碼改得語義變化——它移動的是空白和換行不是邏輯。這句話聽著簡單但很多格式化工具其實是基于正則或 token 流的遇到復(fù)雜的嵌套結(jié)構(gòu)容易“手抖”Black 則穩(wěn)定很多。所以它的“專制”是有底氣的語法預(yù)檢這一步保證了它觸碰的都是格式層而不是語義層。2.2 行寬 88一個有點反直覺的數(shù)字熟悉 PEP 8 的朋友都知道官方建議每行代碼不超過 79 個字符。Black 默認用的卻是 88而且不是隨便拍的。作者發(fā)現(xiàn)把行寬放寬到 88 能顯著減少手動換行和續(xù)行同時又不會讓代碼在常見的 80 列終端上顯得過擠?，F(xiàn)實里79 個字符對現(xiàn)代顯示器來說偏保守但 100 甚至 120 又太寬會讓并排窗口、Git 沖突對比、以及打印代碼的人抓狂。88 是平衡點多出來的 9 個字符換來了“少打斷思路”的體驗。這個參數(shù)可以用--line-length或者在配置文件里覆蓋。不過我的建議是除非你有極其明確的理由第一次用 Black 不要改行寬。團隊里如果為了 88 還是 100 再吵一輪跟之前為 79 還是 88 吵沒有本質(zhì)區(qū)別。選一個默認值然后閉眼接受才是 Black 想給你的“免思考”狀態(tài)。2.3 引號、括號與魔法逗號Black 一個最容易被新用戶發(fā)現(xiàn)的行為就是把字符串統(tǒng)一成雙引號——對于 Python 而言單雙引號在語義上沒區(qū)別但統(tǒng)一后 diff 更干凈切換語言時的習(xí)慣也不至于撕裂。它還會優(yōu)先把整個字符串內(nèi)的引號轉(zhuǎn)成不會沖突的那個比如字符串里已有雙引號外部就用單引號這樣轉(zhuǎn)義最少。括號處理上Black 遵循一個原則能展開就展開能收斂就收斂。當一個函數(shù)調(diào)用、列表、字典長度超過行寬它會優(yōu)先使用“尾隨逗號 每個元素獨立一行”的豎排風(fēng)格。這也是我特別喜歡的功能只要你在最后一項后面手動加了一個逗號Black 就會認定這個結(jié)構(gòu)“應(yīng)該豎排”即使當前版本的行寬只差一點點它也保持豎排而不是縮回去。反過來如果沒加尾隨逗號Black 會盡量把元素收進一行。這個機制讓“多行還是單行”這個決定權(quán)留給了你——通過是否添加尾隨逗號你可以明確表達意圖Black 尊重你的意圖。理解這個原則后你就不會再跟 Black 玩“它為什么把列表拆了又合上”的猜謎游戲了。3. 安裝、集成與讓你的編輯器聽話3.1 用 pip 安裝與版本鎖定Black 的安裝很常規(guī)一行命令即可pip install black但如果你在團隊里我強烈建議鎖定版本。因為 Black 在 1.x 版本之前一直維護著一個“beta”標簽有些輸出格式在新版本里會微調(diào)。同一個文件用 22.1.0 和 23.3.0 格式化結(jié)果可能有細微差異。這會造成“本地跑過CI里又說要改”的詭異現(xiàn)象。所以別用pip install black直接打到環(huán)境里最好在項目里用虛擬環(huán)境并在 requirements-dev.txt 里寫好精確版本black23.3.0如果你用 poetry 或 pipenv同樣把版本鎖死。版本統(tǒng)一是團隊協(xié)作的第一步也是“格式化結(jié)果可復(fù)現(xiàn)”的前提。3.2 命令行實操先看會改哪些再動手日常使用中最常用的是這幾個命令# 檢查文件是否已符合格式不修改 black --check target.py # 輸出格式化前后的 diff不修改 black --diff target.py # 直接改寫文件 black target.py # 遞歸處理整個目錄 black src tests我的工作流通常是在提交之前先跑black --check .看哪些文件不干凈再用--diff快速掃一眼它到底想改什么。因為 Black 雖然可靠但偶爾會有“它想改的我不是很認可”的時刻比如把一個本來已經(jīng)豎排得很整齊的字典硬縮回一行或者把我的長字符串魔法性地重新拼接。先看 diff 再執(zhí)行black .改寫能讓你對所有變更心里有數(shù)不然 commit 時可能出現(xiàn)你根本不了解的大規(guī)模 diff。如果你是第一次對老項目運行 Black請務(wù)必做好心理準備首次格式化可能會產(chǎn)生幾百甚至上千行變更。這不是出 bug而是它一次性把歷史欠賬都清算了。建議第一次格式化單獨提交一次commit message 寫 “style: apply black”后續(xù)再做的功能改動和這次格式變動分得清清楚楚review 時也不會把“改格式”和“改邏輯”混在一起。3.3 在 VS Code 里實現(xiàn)保存即格式化把 Black 的日常使用體驗拉到最舒服的方式是讓它在編輯器里變成基礎(chǔ)能力。VS Code 的 Python 擴展現(xiàn)在原生支持 Black確保 Black 已經(jīng)安裝到當前 Python 環(huán)境。在.vscode/settings.json里加兩行{ python.formatting.provider: black, [python]: { editor.formatOnSave: true, editor.defaultFormatter: ms-python.python } }保存文件時VS Code 就會調(diào) Black 自動格式化當前文件。如果你不想所有文件都這樣也可以把editor.formatOnSave設(shè)為 false然后手動ShiftAltF隨時觸發(fā)。不過既然用了自動格式化我建議直接開“保存即格式化”這才是“無感集成”的完全體。你只需要負責(zé)寫邏輯保存那一瞬間代碼已經(jīng)齊整。PyCharm 用戶則需要額外安裝 Black 插件或者在外部工具里配置。因為 PyCharm 的默認格式化器是它自己的和 Black 的規(guī)則并不完全一致。如果你喜歡 PyCharm 的工程能力但又不愿意丟掉 Black 的統(tǒng)一性配置好插件后讓 PyCharm 的 CtrlAltL 調(diào)用 Black 即可。注意插件需要選擇正確的 Black 解釋器路徑否則會提示找不到 black。3.4 配合 pre-commit 守住院子的大門編輯器格式化屬于“自覺層”真正能強制團隊所有人的是 Git 提交前的鉤子。pre-commit是目前最流行的框架配置一個black鉤子只需要在.pre-commit-config.yaml里加repos: - repo: https://github.com/psf/black rev: 23.3.0 hooks: - id: black language_version: python3首次pre-commit install后每次git commit前都會自動檢查暫存區(qū)的 Python 文件如果不滿足格式它會直接改寫這些文件并把 commit 停下。你重新git add再 commit 就行了。這個機制最厲害的地方在于不規(guī)范代碼根本進不了版本庫。哪怕是經(jīng)驗不足的新人也不會因為風(fēng)格問題被 code review 批評——機器已經(jīng)幫他修好了一切。如果你用的是 pre-commit 舊版本注意rev和你的 Black 實際版本保持一致。否則鉤子會去下載它所指定的版本和本地環(huán)境不一致造成困惑。3.5 在 CI 里當最后一道防線pre-commit 攔的是本地提交但總有繞過的時候有人用--no-verify跳過鉤子或者改了文件直接推送。所以 CI 流水線里加一個格式檢查任務(wù)很有必要命令超簡單black --check --line-length 88 .只要代碼不符合 Black 風(fēng)格這條命令返回非零狀態(tài)碼構(gòu)建就掛。這樣格式規(guī)范就從“軟建議”變成了“硬約束”。GitHub Actions、GitLab CI、Jenkins 里都能輕松塞入。實際落地時建議把black --check放在最前期的檢查階段跟 lint、單測分開才能快速定位問題來源。我觀察到很多團隊沒加 CI 里的格式檢查導(dǎo)致即使裝了 pre-commit 也會偶爾漏網(wǎng)。越大的團隊越需要這種“機器守門員”因為你永遠不知道某個同事是否在沒裝 pre-commit 的環(huán)境下提交了代碼。CI 檢查不會跟人講情面它就是檢查規(guī)則本身沒有例外。4. 實操過程從零到讓一個舊項目重獲新生4.1 動手前先保存一份“格式化前”的現(xiàn)場很多老項目的首次格式化會像地震一樣觸及大量文件。別慌按下面的流程來穩(wěn)得很第一步確保當前工作區(qū)是干凈的git status第二步把當前依賴安裝齊全最好是在一個全新的虛擬環(huán)境里執(zhí)行python -m venv .venv source .venv/bin/activate pip install black23.3.0這里鎖定版本的原因是不同大版本的 Black 對同一段代碼可能給出略微不同的輸出。團隊里首先鎖定的是“用什么規(guī)則”其次才是“誰執(zhí)行規(guī)則”。第三步先跑一遍檢查感受一下舊代碼的“違規(guī)面”有多大black --check --line-length 88 .如果輸出一長串文件列表說明項目已經(jīng)欠下不少格式債。這時不要一股腦全部格式化建議按模塊分批發(fā)包。比如先格式化src/utils再處理src/core每批一次獨立提交。這樣萬一某個模塊在格式化后出現(xiàn)奇怪的運行時錯誤極小概率但不是零能快速定位是哪次變更引入的。4.2 用 pyproject.toml 統(tǒng)一團隊配置Black 的官方推薦是使用 pyproject.toml 承載所有配置。例如[tool.black] line-length 88 target-version [py310] include \.pyi?$ extend-exclude ^/(\\ | migrations/\\ | venv/\\ | docs/\\ ) target-version聲明目標 Python 版本Black 會根據(jù)這個決定一些語法特性是否允許比如想針對 Python 3.9 或更早它就不會把某些只在新版本里才安全的格式調(diào)整出來exclude用來排除migrations、虛擬環(huán)境目錄或生成代碼目錄。為什么排除生成代碼因為那些文件本來就是機器生成如果跑 Black 反而會給后續(xù)重新生成帶來噪音。我一般會把migrations/、docs/還有build/排除掉保留src和tests作為主要格式化目標。如果你用 Django也建議把 migrations 排除不然每次遷移操作后都要 Black 一遍純屬重復(fù)勞動。4.3 實操現(xiàn)場格式化一段“有情緒”的代碼來看一段典型的、未經(jīng) Black 處理的代碼def get_user_info(name,age,emailNone): if email ! None and not in email: raise ValueError(invalid email) user {name: name, age: age} if email: user[email] email return {data: user, status: ok}這段代碼很多東西不符合規(guī)范等號兩邊缺空格、縮進沒問題但是參數(shù)和逗號后沒空格、字符串用單引號、字典里的空格風(fēng)格也不統(tǒng)一。跑一下 Black輸出變成這樣def get_user_info(name, age, emailNone): if email ! None and not in email: raise ValueError(invalid email) user {name: name, age: age} if email: user[email] email return {data: user, status: ok}你發(fā)現(xiàn)沒有Black 做的是機械且一致的處理所有引號統(tǒng)一為雙引號逗號后與運算符周圍補上空格字典等號周圍空格也規(guī)范化。邏輯一行沒改但整個代碼的“呼吸感”出來了。新版 Black 甚至?xí)槺憬ㄗh你把email ! None改成email is not None嗎不會Black 只管格式不做 lint 層面的重構(gòu)。這屬于 ruff 或 pylint 的范疇別把責(zé)任全丟給 Black。4.4 長函數(shù)調(diào)用Black 怎么拆行當函數(shù)調(diào)用或列表太長、超過行寬時Black 會自動展開成多行。比如result requests.post(url, data{a: 1, b: 2}, headersheaders, timeout5)假設(shè)這行超過 88 個字符Black 會變成result requests.post( url, data{a: 1, b: 2}, headersheaders, timeout5, )注意只要某一個參數(shù)本身無法在行寬內(nèi)放下Black 就會把所有參數(shù)豎排保持“完全對齊的混亂”。對這種“爆炸式”展開有人覺得占行數(shù)太多但優(yōu)勢是后續(xù)增刪一個參數(shù)diff 只影響那一行不污染其他行。這是 Git 友好型排版也是 Black 有意為之的設(shè)計。想要讓一個已經(jīng)能放在一行的調(diào)用也保持豎排就在最后一個參數(shù)后加逗號result requests.post( url, data{a: 1, b: 2}, headersheaders, timeout5, ) # 尾隨逗號讓 Black 保持豎排否則它可能把各項收回一行。記住尾隨逗號是你控制 Black 版式的少數(shù)閥門之一。5. 常見問題與排坑實錄5.1 Black 和“魔法逗號”打架前面提到尾隨逗號指示 Black 保持豎排。但有例外如果你的列表或調(diào)用只有一個元素即使有尾隨逗號Black 還是會把它收斂成一行。比如items [1,]會變成items [1,]嗎不會Black 會輸出items [1,]嗎實測它會變成items [1]。只有一個元素的場景豎排沒有意義Black 會忽略你給的尾隨逗號。這個行為早期版本有人吐槽過后來作者從理性的角度解釋單元素豎排純屬浪費行數(shù)不值得為它保留。如果你真的就是想要單元素豎排可以寫注釋阻止格式化但這種情況極少能不用就不用。5.2 字符串拼接與相鄰字符串字面量Black 有一個很討喜的功能就是會自動合并相鄰字符串字面量msg ( Hello, world! )這其實是 Python 解釋器里隱式字符串拼接的寫法Black 不會動它但如果你的字符串超過行寬它不會主動幫你拆分字符串因為那會改變代碼邏輯。遇到超長字符串你先手動思考是不是該用三引號或者分段再交付給 Black。對于 f-string 里的表達式過長Black 會盡量重組但 f-string 本身不支持內(nèi)部換行3.12 前的版本所以過長 f-string 只能讓它橫著耐心等待行寬變大或者重構(gòu)。實際我最常碰到的坑是文檔字符串docstring里的長行。Black 默認不重排 docstring 內(nèi)容因為它認為 docstring 是“散文”不是代碼強行重排可能改變語義。但這樣會造成一個現(xiàn)象docstring 里明明有一長段 120 字符的文本Black 不報錯也不改。很多新手以為是配置問題其實這是設(shè)計選擇。如果你希望 docstring 也被規(guī)范化可以額外采用docformatter工具它專門處理 docstring 格式。5.3 Jupyter Notebook 的格式化Jupyter 里的代碼單元也能用 Black。安裝black[jupyter]后black命令支持.ipynb文件。不過我在本地實驗時發(fā)現(xiàn)筆記本格式化會把代碼單元里的輸出清除不它只改代碼單元輸出保留。但運行 notebook 格式化時要謹慎因為它會改變底層 JSON 文件結(jié)構(gòu)如果你正在協(xié)作或者用 git 頻繁 diff建議設(shè)定專門環(huán)境跑并注意 notebook 的 output 差異也可能被計入 diff。小技巧是在 Notebook 里用魔法命令%load_ext blackcellmagic然后%%black單元格魔法只格式化當前單元不碰別的。5.4 與 isort / autopep8 / yapf 混用Black 只管格式不管 import 排序。常見的組合是 Black isort flake8/ruff。如果你直接裸跑 Blackimport 順序會保持原樣亂序的 import 依然亂序。所以很多項目會引入 isort專門處理 import 排序。但問題來了isort 的默認輸出和 Black 存在沖突比如 isort 喜歡把 import 折行的方式可能與 Black 不一致。解決辦法是在 isort 配置里顯式告訴它使用 Black 兼容模式[tool.isort] profile black這樣兩個工具就不會互相打架。如果你用 Ruff也記得在配置里開啟ruff format還是繼續(xù)依賴 Black。Ruff 的 formatter 從 0.1.0 之后提供ruff format聲稱和 Black 高度兼容但仍有一些邊界差異。團隊里要么定 Ruff要么定 Black不要來回換。5.5 生成代碼、模板文件和第三方目錄前文提過用extend-exclude排除生成代碼非常重要。比如數(shù)據(jù)庫的 migration、自動生成的 protobuf 文件、Jinja 模板中的 Python 片段。對這些文件跑 Black 不僅沒有意義還可能產(chǎn)生巨大的無效 diff。在 CI 里同樣加上排除參數(shù)保持檢查范圍和本地一致。最典型的反面案例是團隊里某個同事把自動生成的models.py跑了一遍 Black后續(xù)每次生成器更新都會產(chǎn)生格式?jīng)_突氣得維護者想把提交歷史倒回去。5.6 版本不一致導(dǎo)致的“幽靈 diff”這是最隱蔽的坑。假設(shè)本地用 Black 23.10.0CI 或隊友用 22.6.0同一個文件格式化結(jié)果可能差幾個字符。代碼在本地看已經(jīng)格式化過推送后 CI 卻報錯。解決辦法就是前文反復(fù)強調(diào)的把 Black 版本固定并且 pyproject.toml、pre-commit 中的rev、requirements 中的版本三者保持一致。版本鎖定到位“幽靈 diff”基本不會出現(xiàn)。6. 在團隊里把 Black 真正用起來6.1 先吵一架再定規(guī)則任何工具引入團隊都會經(jīng)歷“要不要用”的爭論。我遇到最有效的落地方式不是開會投票而是先找一個周末把項目里代表性的幾個文件分別用 Black 和當前團隊的“手寫風(fēng)格”格式化做個對比展示。大多數(shù)時候你會發(fā)現(xiàn) Black 的版本并沒有想象中丑甚至比某些人隨意敲出來的一致得多。那些嚷嚷“Black 毀了我精心設(shè)計的格式”的人曬出來的“精心設(shè)計”往往也就是多空了幾行并不具備系統(tǒng)性價值。關(guān)鍵是讓團隊意識到格式風(fēng)格統(tǒng)一帶來的收益遠超個體對美的堅持。執(zhí)行步驟建議挑選一個業(yè)務(wù)影響不大、但文件數(shù)足夠多的模塊作為試點。格式化后在 code review 里只討論格式不混入功能改動。跑一段時間比如兩個迭代收集大家真實感觀。如果團隊一致認為 Black 對協(xié)作確實有正向作用再逐步鋪開到整個項目。6.2 與 code review 習(xí)慣的整合引入 Black 后code review 的關(guān)注點應(yīng)該徹底轉(zhuǎn)向邏輯、邊界條件、可維護性。如果還有人提起“你這行的逗號風(fēng)格和我不一樣”那就說明團隊還沒真正切換到機器統(tǒng)一風(fēng)格。我常用的一句口頭禪是“格式問題交給 Black咱們管點人腦該管的事?！边@不是矯情而是自動格式化工具的核心價值。Code review 的質(zhì)檢清單里加一條“是否運行 black --check”比review 時肉眼盯格式高效百倍。6.3 格式化即重構(gòu)的低風(fēng)險敲門磚牽引到更宏觀的視角Black 也是一種低風(fēng)險的風(fēng)格統(tǒng)一化手段。當你準備對一個舊項目做大規(guī)模重構(gòu)時先跑一遍 Black 形成干凈的基線后續(xù)用語義化提交、模塊化重構(gòu)都更容易追蹤。歷史經(jīng)驗表明格式化后的代碼更容易閱讀也更容易讓自動化工具比如靜態(tài)檢查準確識別結(jié)構(gòu)。至少我在處理一些老庫時先 Black 一波再重構(gòu)心理壓力會小很多——畢竟代碼在不同人記憶中是不同的統(tǒng)一風(fēng)格后再查具體邏輯定位速度會有明顯提升。7. 我的個人體會與小技巧最后分享幾個我用 Black 這幾年攢下來的私人技巧。第一把 Black 放進 pre-commit 時rev不要寫一個永不更新的分支名而是寫死版本號。我曾經(jīng)見過有人寫rev: main結(jié)果某天 Black 上游更新了一個不兼容的格式輸出全組提交突然全部失敗排查半天才發(fā)現(xiàn)是鉤子“被”升級了。寫死版本升級時主動為之才有可控性。第二如果你有大量手動格式化習(xí)慣剛切換到 Black 的前一兩周會很不適應(yīng)。你會本能地想補上某個它刪掉的空行。我的建議是忍。每次都主動用black --diff看看它究竟要做什么了解它的“脾氣”后你會慢慢發(fā)現(xiàn)它刪空行的規(guī)則其實是“最多連續(xù)兩個空行不搞花式分段”。一旦適應(yīng)了你寫代碼時就會下意識配合它格式率幾乎 100%。第三關(guān)于--fast選項Black 默認在做格式化時還會解析語法如果你確信文件沒有語法錯誤可以用--fast跳過某些語法安全檢查來提速。說實話日常項目里沒必要省那十幾毫秒但如果你是 pre-commit 掛在大型 monorepo 上且文件極多--fast能明顯讓提交變快。風(fēng)險是遇到一個語法邊緣情況 Black 不會提示你可能輸出一個不可解析的結(jié)果。所以我只在 CI 里用默認模式本地開發(fā)為了體驗才開--fast。第四Black 和 Python 版本的支持新版 Black 要求 Python 3.8如果你還想支持 Python 3.7得用black22.12.0這類老版本。這個坑不太起眼但真的要部署在老系統(tǒng)上時記得查 Black 自身的最低 Python 要求別以為它只是個工具就能“萬能適配”。第五常備一個“格式化后再讀一遍”的習(xí)慣。Black 雖然不改變語義但有時它會為了排版把一個復(fù)雜的表達式拆成極其抽象的多行結(jié)構(gòu)可讀性反而下降。這時不要硬忍著可以提取一個中間變量或者加注釋讓代碼更清晰。Black 是底線不是天花板——它保證下限統(tǒng)一但代碼質(zhì)量的上限要靠你的設(shè)計能力。工具是死的團隊是活的。讓 Black 管住那些不值得人類動腦子的格式問題你就能把時間花在真正值錢的地方模塊劃分、性能優(yōu)化、業(yè)務(wù)理解。我做技術(shù)負責(zé)人的這幾年見過太多為“對齊方式”吵到面紅耳赤的場面也見過引入 Black 后 review 效率明顯回升的團隊。如果你還沒試過挑一個小項目裝一個 Black跑一次black .你大概率會和我一樣再也不想手捏格式了。