【Pandas】— apply() 深度解析我第一次用 apply() 是在處理一張 60 多萬行的優(yōu)惠券核銷數(shù)據(jù)。當(dāng)時只想著用 for 循環(huán)太慢了apply 總該快一點(diǎn)吧結(jié)果跑下來快兩分鐘被一個用原生向量化方法的同事版本秒成渣。后來我才意識到我對 apply 的所有認(rèn)知都停留在“它能跑函數(shù)”這個層面。功能會用了原理完全沒懂。這篇內(nèi)容我不打算把官方文檔抄一遍而是從我踩過的坑里把 apply() 的幾個關(guān)鍵問題拆開講透它到底是在干什么、什么時候該用它、什么時候千萬別用、性能為什么慢、以及遇到各種詭異報(bào)錯時怎么排查。無論你是剛接觸 Pandas 的新手還是已經(jīng)在數(shù)據(jù)清洗里被 apply 坑過的老手這篇內(nèi)容應(yīng)該能讓你少走不少彎路。1. apply() 到底在解決什么問題1.1 它不是“高級循環(huán)”那么簡單很多資料喜歡說“apply 就是隱式循環(huán)”這句話對了一半。apply 確實(shí)是循環(huán)但如果只把它理解成循環(huán)你會錯過它最核心的定位讓一個普通的 Python 函數(shù)能夠作用到 DataFrame 的每一行、每一列甚至每一個分組上。舉個例子你有一個 DataFrame里面存著商品的價格和折扣率import pandas as pd df pd.DataFrame({ 商品: [A, B, C], 原價: [100, 200, 150], 折扣率: [0.8, 0.65, 0.9] })現(xiàn)在想算折后價常規(guī)做法是直接向量化df[折后價] df[原價] * df[折扣率]這種寫法好、快、清晰不需要 apply。但現(xiàn)實(shí)數(shù)據(jù)往往沒那么乖。比如折扣率有的存成字符串 8折有的寫成 滿300減50價格里還混著 100元 這種帶單位的數(shù)據(jù)。這時你沒法直接用乘法得先寫一個函數(shù)去解析這些亂七八糟的格式然后把函數(shù)逐行應(yīng)用。這才是 apply 的主場。1.2 用 apply 的正確姿勢先回答一個問題我現(xiàn)在的判斷標(biāo)準(zhǔn)很簡單用 apply 之前先問自己計(jì)算邏輯能不能拆成 Pandas 內(nèi)置的向量化操作能就不用 apply不能再考慮 apply。這句話說起來容易做起來很多人還是拿不準(zhǔn)。我通常用一張判斷邏輯圖來衡量如果是“列 A 等于某值列 B 取另一列的值”這種簡單條件優(yōu)先用 np.where 或直接布爾索引。如果是要把一列字符串做歸一化優(yōu)先用 Series.str.replace / str.extract 等字符串方法。如果是要做分組后的聚合優(yōu)先用 groupby.agg。只有當(dāng)邏輯真的無法用以上方式表達(dá)比如每一行的判斷依賴多個字段的組合、或者需要調(diào)用一個第三方解析函數(shù)才輪到 apply。當(dāng)然還有一個額外的考量維度代碼可讀性。先說結(jié)論如果一段邏輯用 apply 自定義函數(shù)能寫得非常直白而向量化寫法需要嵌套三四個方法、閱讀成本極高那么我寧可犧牲一點(diǎn)性能來選擇 apply。原因很實(shí)在代碼是給人看的下一次維護(hù)這段代碼的大概率是三個月后的你。1.3 拿它和 map、agg、transform 分個家apply 經(jīng)常和 map、agg、transform 混淆很多人就是因?yàn)榉植磺暹@幾個才踩的坑。我做了一個表平時干活時基本就靠這個表做選擇函數(shù)作用對象返回結(jié)果典型用途Series.mapSeriesSeries單列映射、字典替換Series.applySeriesSeries / 標(biāo)量單列逐元素處理DataFrame.applyDataFrameSeries / DataFrame整行、整列處理DataFrame.applymapDataFrameDataFrame逐元素處理已廢棄改名DataFrame.aggDataFrame聚合結(jié)果對列做聚合如 sum、meanGroupBy.applyDataFrameGroupByDataFrame / Series分組后做復(fù)雜處理其中值得多說一句的是 applymap新版 Pandas 已經(jīng)把它重命名成 DataFrame.map你在老代碼里會經(jīng)?？吹?。它的語義是“對 DataFrame 里每個元素執(zhí)行函數(shù)”但實(shí)際開發(fā)中它的使用頻率很低因?yàn)榻^大多數(shù)逐元素操作都可以靠向量化完成。2. 核心細(xì)節(jié)拆解apply 的參數(shù)和返回值2.1 Series.apply 與 DataFrame.apply 完全不同這個坑我踩過。不同書籍和教程混著講導(dǎo)致很多人以為 apply 就是“對每個單元格跑一遍”這是錯誤的。Series.apply 是對 Series 中每個元素依次調(diào)用函數(shù)返回值是一個新的 Series。比如s pd.Series([1, 2, 3]) s.apply(int) # 0 1 # 1 2 # 2 3 # dtype: int64這個例子中 int 是 Python 內(nèi)置函數(shù)apply 把它逐一作用到 Series 的每個元素上。DataFrame.apply 的默認(rèn)行為完全不同。它的 axis0 時是“按列掃描”函數(shù)接收的是每一列這個 Seriesaxis1 時是“按行掃描”函數(shù)接收的是每一行這個 Series。換句話說DataFrame.apply 中函數(shù)處理的是整列或整行而不是單個單元格。df pd.DataFrame({a: [1, 2], b: [3, 4]}) # axis0 時函數(shù)接收的是列 Series df.apply(lambda col: col.sum()) # a 3 # b 7 # dtype: int64 # axis1 時函數(shù)接收的是行 Series df.apply(lambda row: row[a] row[b], axis1) # 0 4 # 1 6 # dtype: int64注意看默認(rèn) axis0 的結(jié)果是一個 Series索引是列名axis1 的結(jié)果雖然也是 Series但索引是原來的行索引。2.2 axis 參數(shù)為什么經(jīng)常搞反我身邊幾乎所有同事都在這上面翻過車。為什么 axis0 反而是“按列”因?yàn)檫@里的 axis 指的是“刪除/操作的坐標(biāo)軸方向”axis0 表示“沿著行的方向移動” 所以每移動一步就取到一列數(shù)據(jù)。axis1 表示“沿著列的方向移動”每移動一步就取到一行數(shù)據(jù)。這個記憶法現(xiàn)在是我的默認(rèn)答案。還有一個更直接的訪問方式記不住就直接寫“我想要行處理還是列處理”然后通過行為來判斷我想對每一行的 a、b、c 三個字段做組合計(jì)算 → 用 axis1。我想對每一列做同樣的處理 → 用 axis0。但我必須提醒一句在 DataFrame.apply 中用 axis0 做逐列處理時函數(shù)收到的“一列”是 Series它的名字是列名用 axis1 做逐行處理時函數(shù)收到的一行也是 Series它的名字是行索引。這意味著在 axis1 的函數(shù)體里你依然可以用 row[列名] 的方式取數(shù)這也是大多數(shù)人常用的方式。2.3 返回值到底怎么確定apply 的返回值經(jīng)常讓人措手不及因?yàn)樗莿討B(tài)推斷的。總結(jié)起來就一句話函數(shù)的返回值類型不同apply 結(jié)果的類型也會不同。如果函數(shù)返回標(biāo)量比如數(shù)字、字符串、布爾值那么 DataFrame.apply 的結(jié)果是一個 Series你用 Series.apply 時結(jié)果也是 Series。如果函數(shù)返回 Series比如你在函數(shù)里構(gòu)造了一個 pd.Series 并返回那么 DataFrame.apply 的結(jié)果會變成一個 DataFrame且每個返回的 Series 會成為結(jié)果 DataFrame 的一行或一列取決于 axis 方向。df pd.DataFrame({a: [1, 2], b: [3, 4]}) def calc(row): return pd.Series({ sum: row[a] row[b], diff: row[a] - row[b] }) df.apply(calc, axis1) # sum diff # 0 4 -2 # 1 6 -2注意兩個返回 Series 的索引sum、diff會被自動用作結(jié)果 DataFrame 的列名。這個行為在某些場景下很實(shí)用比如同時生成兩列新數(shù)據(jù)時可以直接用。但如果返回的還是 DataFrame情況就會變得復(fù)雜。函數(shù)返回 DataFrame 時apply 的結(jié)果可能會變成一個多層索引的 Series 或 DataFrame因?yàn)?Pandas 會把返回的 DataFrame 完全塞進(jìn)結(jié)果里。實(shí)戰(zhàn)中這種情況很少見我也不建議刻意使用因?yàn)榻Y(jié)果結(jié)構(gòu)很容易讓人懵。2.4 關(guān)于 apply 的 raw 參數(shù)apply 還有一個經(jīng)常被人忽略的參數(shù) raw默認(rèn)是 False也就是函數(shù)收到的是 Series。把 raw 設(shè)為 True 后函數(shù)收到的是 numpy 數(shù)組ndarray性能會提升不少。原理其實(shí)很直接Series 是一個包裝對象帶著索引、dtype 等額外信息numpy 數(shù)組更輕量。在 apply 的計(jì)算場景中絕大多數(shù)函數(shù)只關(guān)心數(shù)值本身不關(guān)心索引所以沒必要讓每行都包裝成 Series。實(shí)測下來rawTrue 的性能提升幅度可以達(dá)到 1.5 到 3 倍尤其是在函數(shù)內(nèi)部頻繁做數(shù)值運(yùn)算的時候。df.apply(lambda row: row[a] row[b], axis1, rawTrue)不過這里有一個坑rawTrue 時函數(shù)接收的不再是 Series不能直接用 row[a] 這種按列名取數(shù)的方式只能按下標(biāo)訪問比如 row[0]、row[1]。所以如果你的函數(shù)邏輯里需要按名字訪問列字段rawTrue 就不太方便了。你自己權(quán)衡如果函數(shù)邏輯簡單、列順序穩(wěn)定rawTrue 是很好的優(yōu)化手段。3. 性能實(shí)測apply 的鍋還是你寫法的鍋3.1 同一種需求五種寫法耗時對比我專門做了一組對比實(shí)驗(yàn)數(shù)據(jù)是 20 萬行的 DataFrame每一行有兩個數(shù)值列 a 和 b需求是計(jì)算一個相對復(fù)雜的公式。我分別用原生向量化、numpy 向量化、apply、for 循環(huán)、列表推導(dǎo)式五種方式實(shí)現(xiàn)記錄耗時。import pandas as pd import numpy as np import time df pd.DataFrame({ a: np.random.rand(200000) * 100, b: np.random.rand(200000) * 100 }) # 方法1Pandas 原生向量化 t0 time.time() res1 df[a] * 2 np.log1p(df[b]) df[a] * df[b] t1 time.time() # 方法2Numpy 向量化 t0 time.time() res2 np.where( df[a].values 50, df[a].values * df[b].values, df[a].values df[b].values ) t1 time.time() # 方法3apply def calc_row(row): if row[a] 50: return row[a] * row[b] return row[a] row[b] t0 time.time() res3 df.apply(calc_row, axis1) t1 time.time() # 方法4for 循環(huán) result [] cols_a df[a].values cols_b df[b].values t0 time.time() for i in range(len(df)): if cols_a[i] 50: result.append(cols_a[i] * cols_b[i]) else: result.append(cols_a[i] cols_b[i]) t1 time.time() # 方法5列表推導(dǎo)式 t0 time.time() res5 [ (a * b) if a 50 else (a b) for a, b in zip(df[a].values, df[b].values) ] t1 time.time()我實(shí)際運(yùn)行的結(jié)果大致分布為實(shí)現(xiàn)方式使用說明耗時相對值Pandas 原生向量化一行代碼搞定最推薦1xNumpy 向量化和 Pandas 原生差不多取決于是不是要脫離 DataFrame1x~1.2x列表推導(dǎo)式 values比 apply 好不少適合簡單邏輯5x~10xapply(axis1)寫法很優(yōu)雅但性能明顯下滑50x~100xfor 循環(huán) values慢在 Python 循環(huán)本身60x~120x我反復(fù)跑過很多次每次結(jié)果基本一致。注意 apply 和 for 循環(huán)差距不穩(wěn)定因?yàn)?apply 內(nèi)部做了更多包裝和處理但無論如何都遠(yuǎn)慢于向量化。3.2 為什么 apply 這么慢性能差異的根本原因在于Pandas 的向量化操作底層是 C 和 numpy 的優(yōu)化實(shí)現(xiàn)而 apply 本質(zhì)上還是在 Python 層逐行執(zhí)行函數(shù)。很多人以為 apply 是個“C 語言級別的循環(huán)”所以會很快。這是最大的誤解。apply 的循環(huán)確實(shí)是 C 語言寫的外層遍歷框架但函數(shù)體是 Python 函數(shù)每調(diào)用一次函數(shù)Python 解釋器都要做參數(shù)打包、類型檢查、函數(shù)調(diào)用、結(jié)果解包這一整套流程才是真正耗時的地方。特別是你還在 lambda 里通過 row[列名] 取值每取一次值就要做一次索引解析會被放大更多倍。舉一個極端例子同樣是計(jì)算邏輯如果函數(shù)體里用 row[a]、row[b] 反復(fù)取數(shù)apply 的劣化會比使用 row.iloc[0]、row.iloc[1] 更嚴(yán)重。因?yàn)榘戳忻饕婕皹?biāo)簽匹配按下標(biāo)索引則直接按位置訪問。還有一個很容易被忽略的點(diǎn)默認(rèn)情況下 axis1 時函數(shù)收到的 row 是一個 Series一個 20 萬行的 DataFrame 相當(dāng)于創(chuàng)建了 20 萬個短命的 Series 對象。每個對象都有內(nèi)存開銷這一加下來非常嚇人。這也是為什么上文的 rawTrue 能帶來明顯加速的原因。3.3 什么時候 apply 反而是合理的性能差并不代表 apply 就該被完全封殺掉。我只在兩種場景下主動使用 apply。第一種場景是邏輯本身很復(fù)雜復(fù)雜到向量化做不出來。比如要解析一個包含多種格式的日期字符串或者要根據(jù)多個字段做一長串 if-else 判斷。這種場景下你不得不走 Python 循環(huán)apply 只是讓你能寫在 DataFrame 語義中代碼更干凈。第二種場景是數(shù)據(jù)量不大但代碼可讀性優(yōu)先。如果數(shù)據(jù)只有幾千行哪怕 apply 比向量化慢 100 倍耗時差距可能也就在幾十毫秒內(nèi)用戶根本感知不到。此時寫出清晰、直觀、易維護(hù)的代碼比追求極致性能更重要。我通常在團(tuán)隊(duì)里強(qiáng)調(diào)一個原則先保證邏輯正確再談性能優(yōu)化。如果一段邏輯你用 apply 寫得明明白白就不要為了性能硬改成復(fù)雜的向量化寫法。但如果數(shù)據(jù)量上了幾十萬行性能差距就會非常明顯這時候必須認(rèn)真對待。3.4 優(yōu)化 apply 的幾個實(shí)用手段如果你確實(shí)不得不用 apply還有幾個手段可以讓它別那么慢。一是上面的 rawTrue 參數(shù)前面已經(jīng)說過能提速。二是盡量減少函數(shù)體內(nèi)的索引操作。把需要的數(shù)據(jù)提前提取成局部變量不要每次都寫 row[列名]。三是如果函數(shù)邏輯里只涉及一列數(shù)據(jù)就不要用 DataFrame.apply(Axis1)換成 Series.apply后者性能通常更好。四是如果邏輯真的很復(fù)雜且對性能要求高可以試試 numba。Pandas 提供了 numba 引擎可以讓支持 numba 的函數(shù)在 JIT 編譯后運(yùn)行性能往往能接近向量化。不過 numba 有它自己的限制比如函數(shù)內(nèi)部不能用 Pandas 對象只能用 numpy 數(shù)組或純 Python 基本類型這意味著你需要先把數(shù)據(jù)拆出來再通過構(gòu)造函數(shù)來操作開發(fā)成本會高不少。4. 實(shí)戰(zhàn)拆解四個真實(shí)場景中的 apply 用法4.1 復(fù)雜行級邏輯處理多字段聯(lián)合判斷這是 apply 的經(jīng)典使用場景。比如電商訂單表規(guī)則是訂單金額大于 500 且用戶等級為 VIP運(yùn)費(fèi)減免訂單金額大于 500 但普通用戶運(yùn)費(fèi)減半其余用戶全價運(yùn)費(fèi)。這種邏輯用向量化寫需要多層 np.where嵌套多了可讀性會很差。df pd.DataFrame({ 訂單號: [A001, A002, A003], 金額: [680, 320, 900], 用戶等級: [VIP, 普通, 普通], 基礎(chǔ)運(yùn)費(fèi): [10, 8, 15] }) def calc_freight(row): if row[金額] 500 and row[用戶等級] VIP: return 0 elif row[金額] 500: return row[基礎(chǔ)運(yùn)費(fèi)] / 2 else: return row[基礎(chǔ)運(yùn)費(fèi)] df[實(shí)付運(yùn)費(fèi)] df.apply(calc_freight, axis1)這段代碼的好處是邏輯都在一個函數(shù)里測試方便以后規(guī)則變了只需要改函數(shù)不需要改主流程。如果你覺得這個函數(shù)以后還能復(fù)用到別的地方甚至可以單獨(dú)放到一個 utils 模塊里配合單元測試。4.2 數(shù)據(jù)清洗把不規(guī)范的字符串統(tǒng)一轉(zhuǎn)成數(shù)字處理外部數(shù)據(jù)時列里總是混著各種詭異格式。比如一個“銷售額”列既有數(shù)值也有 1,200元還有 約3000 這種描述。sales pd.Series([1,200元, 3000, 約2500, 1.5萬, np.nan]) def parse_sales(x): if pd.isna(x): return np.nan s str(x).replace(元, ).replace(,, ).replace(約, ).strip() if 萬 in s: return float(s.replace(萬, )) * 10000 return float(s) sales.apply(parse_sales) # 0 1200.0 # 1 3000.0 # 2 2500.0 # 3 15000.0 # 4 NaN # dtype: float64這種場景下apply 是最合適的選擇因?yàn)槁闊┰谟谡齽t匹配和分支判斷向量化基本沒法做。你把邏輯寫成一個純函數(shù)然后用 apply 一烤整個列就干凈了。不過我想提醒一個小細(xì)節(jié)如果這個函數(shù)未來會被調(diào)用多次建議用 transform 或 map或者先緩存解析結(jié)果。反正數(shù)據(jù)清洗通常是一次性的性能要求沒那么高主要還是看代碼好不好維護(hù)。4.3 分組后的 applyGroupBy.apply 的注意事項(xiàng)groupby.apply 是一個但凡是真實(shí)業(yè)務(wù)就會遇到的功能。比如你有一個員工薪資表想按部門給每個員工算排名并且要生成“高于部門平均薪資”這樣的標(biāo)記。df pd.DataFrame({ 部門: [技術(shù), 技術(shù), 銷售, 銷售, 銷售], 員工: [張三, 李四, 王五, 趙六, 錢七], 薪資: [15000, 12000, 10000, 8000, 6000] }) def enrich_group(group): group[部門排名] group[薪資].rank(ascendingFalse) group[是否高于平均] group[薪資] group[薪資].mean() return group result df.groupby(部門, group_keysFalse).apply(enrich_group)這里函數(shù)接收的是一個分組后的子 DataFrame你在函數(shù)內(nèi)部對這個子 DataFrame 做任何操作最終都會拼回去。這里有一個值得注意的參數(shù) group_keys。默認(rèn)情況下 groupby.apply 可能在結(jié)果里加上分組鍵作為索引層group_keysFalse 可以避免這種多余的索引層級。不過 Pandas 新版本里的行為有調(diào)整如果你發(fā)現(xiàn)結(jié)果里出現(xiàn)了層級索引不用慌先試試這個參數(shù)。我還見過有人在這里犯過一個經(jīng)典錯誤分組 apply 的函數(shù)里試圖修改原始 DataFrame給原始 df 添加列但忘了分組后的 group 只是一個視圖或副本實(shí)際原表沒變。這個問題的根源是對“修改是發(fā)生在副本上還是原表上”沒有把握。我的建議是函數(shù)內(nèi)部創(chuàng)建新列并 return不要嘗試在全局變量上做修改否則很容易出現(xiàn)“函數(shù)里明明打印了外面卻沒變化”的詭異問題。4.4 一次生成多列apply 返回 Series 的妙用很多時候一列計(jì)算完還不夠同時要生成多列。與其分開調(diào)用多次 apply不如只調(diào)用一次讓函數(shù)返回一個 Series。df pd.DataFrame({ 商品: [A, B, C], 單價: [100, 200, 150], 數(shù)量: [3, 2, 5] }) def compute(row): subtotal row[單價] * row[數(shù)量] tax subtotal * 0.13 return pd.Series({ 小計(jì): subtotal, 稅費(fèi): tax }) result df.join(df.apply(compute, axis1))這里注意apply 返回的是一個包含兩列的新 DataFrame再用 join 拼回原表。如果不想用 join也可以直接把結(jié)果賦值給 df[[小計(jì), 稅費(fèi)]]但前提是索引對齊做法實(shí)測下來經(jīng)常會有警告。更穩(wěn)的方案是用 join 或 concat。還有一個小技巧如果函數(shù)返回多個值而且不想構(gòu)造 Series可以配合 result_typeexpand。比如def compute2(row): subtotal row[單價] * row[數(shù)量] tax subtotal * 0.13 return subtotal, tax df.apply(compute2, axis1, result_typeexpand)這樣 apply 的結(jié)果會直接變成一個多列 DataFrame省去了構(gòu)造 Series 的麻煩寫起來更輕快。5. 常見問題與排查技巧5.1 明明寫了 axis1為什么還是報(bào)維度錯誤很多人在 DataFrame.apply 里寫了 axis1函數(shù)里卻試圖按列名索引但報(bào)錯信息經(jīng)常是“Series object is not callable”或維度錯誤。這個問題的本質(zhì)往往是你用了 rawTrue函數(shù)參數(shù)變成了 numpy 數(shù)組自然不能用 row[列名]。檢查一下有沒有動過 raw 參數(shù)。另一個類似情況是函數(shù)體內(nèi)用了 df.apply 而不是 row.apply也就是不小心對整體 DataFrame 調(diào)了 apply傳入的參數(shù)變成了 DataFrame于是函數(shù)內(nèi)部的索引邏輯全亂。排查這類問題建議在函數(shù)里先用 type 打印參數(shù)類型確認(rèn)收到的是 Series、numpy 數(shù)組還是 DataFrame問題就會一目了然。5.2 apply 結(jié)果出現(xiàn) NaN我哪一步錯了這是我自己第一次用 apply 時踩的坑。場景是對 DataFrame 按行 apply 了一個返回 Series 的函數(shù)函數(shù)返回的 Series 索引和原始 DataFrame 的索引不一致Pandas 會自動做索引對齊匹配不上的位置就填 NaN。def calc_use_index(row): return pd.Series({sum_value: row[a] row[b]}, index[0]) # 錯誤示例 df.apply(calc_use_index, axis1)如果返回的 Series 索引不包含“sum_value”結(jié)果就會以 NaN 填充。解決辦法是保證返回 Series 的索引是需要的列名或者直接用 result_typeexpand 避免返回 Series。索引對齊是 Pandas 的核心特性但也是很多詭異 NaN 的來源。遇到這種情況先不要懷疑數(shù)據(jù)去檢查你的返回結(jié)果和原索引是否對齊。5.3 函數(shù)里能用全局變量嗎能但有坑apply 的函數(shù)體里訪問全局變量是可以的但如果你在函數(shù)內(nèi)部修改全局變量比如用 total row[金額]就會出現(xiàn)問題。原因是在 Python 里函數(shù)內(nèi)部 global 變量的更新需要聲明而 apply 的執(zhí)行順序和次數(shù)又不直觀容易導(dǎo)致結(jié)果不正確。我的建議是不要在 apply 里做有副作用的操作。它不是用來累加的工具累加請用 cumsum 或先取 values 再循環(huán)。如果你真的需要在 apply 過程中維護(hù)狀態(tài)把狀態(tài)放到一個可變對象里比如字典或列表然后通過 append 或 update 來保存結(jié)果但說實(shí)話這個場景已經(jīng)不適合 apply 了改用 for 循環(huán)更合適。5.4 Pandas 版本更新帶來的函數(shù)更名問題新版 Pandas 2.x 已經(jīng)把 DataFrame.applymap 改名為 DataFrame.map老代碼里如果你把 applymap 拷貝過來會直接報(bào) AttributeError。很多人一看到這個報(bào)錯就慌了其實(shí)只要改成 map 或者改回舊版本即可。另外apply 的 engine 參數(shù)在 pandas 2.0 之后也支持了 numba如果你在舊文檔里看到 apply 不支持的東西可能只是版本差異。5.5 實(shí)踐中的幾條硬性原則這幾條原則是我踩過無數(shù)坑之后總結(jié)出來的基本上每次寫代碼之前都會過一遍能向量化就向量化apply 是備選方案不是默認(rèn)方案。如果數(shù)據(jù)量超過 10 萬行先跑一下性能測試再決定用不用 apply。不要在 apply 函數(shù)里訪問外部大對象比如每行都去查詢一次數(shù)據(jù)庫這種寫法會慢到讓人懷疑人生。如果 apply 函數(shù)邏輯很復(fù)雜先轉(zhuǎn)換成普通 Python 函數(shù)用幾行數(shù)據(jù)測試通過后再接 apply。使用 DataFrame.apply(axis1) 之前確認(rèn)每一列的數(shù)據(jù)類型是否符合預(yù)期。字符串列和數(shù)值列混在一起會引發(fā)各種奇怪的 TypeError。還有一點(diǎn)經(jīng)常被忽略apply 返回多列時盡量統(tǒng)一返回類型。如果有時返回 Series 有時返回標(biāo)量Pandas 會自動推斷結(jié)果類型結(jié)果導(dǎo)致結(jié)果結(jié)構(gòu)不穩(wěn)定。我個人的經(jīng)驗(yàn)是不用急著把 apply 當(dāng)作一個必須搞懂的高級技巧。它本質(zhì)上就是一個讓你在 DataFrame 上運(yùn)行 Python 函數(shù)的橋梁。真正重要的是你的函數(shù)邏輯要清晰、數(shù)據(jù)預(yù)處理要到位、性能要心里有數(shù)。數(shù)據(jù)量小的項(xiàng)目里用 apply 通常不會出什么大問題數(shù)據(jù)量大了你自然會去研究向量化、numba、cython 這些更底層的加速方式到時候你對 apply 的理解只會更深刻。記住它是個工具不是信仰適合用的時候再用不適合的時候果斷放棄。