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