有一次接手一份銷售明細表三萬多行兩個關鍵字段各有幾百個空。當時第一反應是dropna()一行刪干凈結果跑完發(fā)現(xiàn)月度匯總對不上——被刪掉的很多是同一張訂單的不同商品行刪掉一行整張單的金額就少一塊。那次之后我才真正把 Pandas 缺失值處理當成一個需要做決策的環(huán)節(jié)而不是一句fillna(0)就收工。這一節(jié)聊的就是填充這條路線什么時候能補、補什么值、補完之后數(shù)據(jù)的結構和類型會不會偷偷變形。它適合已經(jīng)會寫isna()和dropna()、但在真實臟數(shù)據(jù)上總是補出問題的朋友也適合剛看完前幾節(jié)、想看看工程里到底怎么落地的人。填充是缺失值處理里自由度最大、也最容易翻車的一環(huán)因為它不像刪除那樣有明確的邊界補什么值完全取決于你對業(yè)務的理解。1. 從刪掉到補回去這一節(jié)要解決的是形狀保持問題1.1 前三節(jié)留下的尾巴數(shù)據(jù)不能隨便丟刪除法之所以簡單是因為它把決策權交給了行數(shù)。只要dropna的參數(shù)一調(diào)剩下多少行是確定的你不用思考每一行的含義。但真實業(yè)務里行往往帶著身份。一條訂單記錄、一條用戶行為日志、一條設備采樣刪掉它等于抹掉一個事實。特別是當你后面要做同比、環(huán)比、留存、漏斗這類強依賴行數(shù)完整性的分析時缺失行會被算成沒發(fā)生而不是沒記錄這兩種含義在業(yè)務上差得很遠。我見過一種很典型的錯誤某次做日活統(tǒng)計先dropna(subset[user_id])再nunique()結果日活比后臺報表低了百分之十幾。原因不是數(shù)據(jù)錯了而是user_id缺失的那批記錄被當成無效行清掉了可它們在業(yè)務口徑里屬于未登錄訪客是要算進某些指標的。這就是刪除法的隱性代價——它不報錯只是悄悄改變了分母。所以進入填充環(huán)節(jié)之前先問自己一個問題這一列的缺失代表沒有這個值還是這個值沒被記錄前者可以考慮填一個語義占位符后者更適合刪除或單獨標記。這個問題沒有標準答案但你必須回答因為后面每一個fillna的取值都由它決定。1.2 填充的三條路線與它們的代價工程里常見的填充思路大致分三類代價各不相同我把它整理成一張表方便你對著場景選路線典型寫法適用場景主要代價常量填充fillna(0)、fillna(未知)缺失本身有業(yè)務含義或后續(xù)要單獨統(tǒng)計會稀釋均值可能掩蓋異常統(tǒng)計量填充fillna(mean/median/mode)數(shù)值型特征、缺失比例不高低估方差破壞列間相關性前后值填充ffill()、bfill()、interpolate()時間序列、有順序的流水數(shù)據(jù)依賴順序假設順序錯了結果全錯常量填充最省事但最容易被濫用。fillna(0)放在金額列上會讓沒記錄金額和金額為零混成一類后面做分布統(tǒng)計時均值直接往下掉。fillna(未知)放在類別列上相對安全因為字符串本身就是一個明確的類別標簽后續(xù)做value_counts()也不會丟信息。我的習慣是數(shù)值列優(yōu)先考慮中位數(shù)或業(yè)務基準值類別列優(yōu)先考慮未知這類顯式標簽只有確實存在零這個業(yè)務事實的場景才填 0。統(tǒng)計量填充的核心風險是方差收縮。用中位數(shù)填一百個空這一百個點的取值全部壓到同一個數(shù)上列的離散程度被人為壓平。如果你后面要用這列做回歸或者做異常檢測這個影響是實實在在的。前后值填充則完全依賴順序假設一旦數(shù)據(jù)沒有按正確的時間或編號排好序ffill()會把不相鄰的記錄串到一起這種錯誤在結果上很難看出來因為補出來的值本身是合理的。1.3 先做一次缺失畫像再決定補不補動手之前我一般會先跑幾行代碼把缺失的分布摸清楚這一步花不了一分鐘但能省掉后面大量返工import pandas as pd import numpy as np df pd.read_csv(orders.csv) # 每列缺失數(shù)量與比例 profile pd.DataFrame({ missing: df.isna().sum(), ratio: df.isna().mean().round(4), dtype: df.dtypes.astype(str), }) print(profile.sort_values(ratio, ascendingFalse)) # 每行缺失了幾個字段 df[_miss_cnt] df.isna().sum(axis1) print(df[_miss_cnt].value_counts().sort_index())df.isna().mean()這個寫法比sum()/len(df)更穩(wěn)因為它在空表上不會除零報錯?？唇Y果的時候我關注三件事第一有沒有某一列缺失比例超過一半這種列填充的意義已經(jīng)不大更該考慮整列丟棄或者單獨建一個是否有值的標記列第二缺失是不是集中在少數(shù)幾行上如果_miss_cnt的分布里有一批行缺了七八個字段那基本可以判定是采集環(huán)節(jié)斷掉了這批行應該單獨隔離而不是粗暴填充第三缺失比例在dtype上有沒有規(guī)律比如所有object列都缺那多半是導出時字符編碼或空字符串的問題。提示_miss_cnt這種工作列記得在用完之后刪掉別讓它跟著數(shù)據(jù)流進下游否則某天你會發(fā)現(xiàn)模型里多了一個莫名其妙的特征。2. isna 判不出來就等于沒缺失假缺失的識別與清洗前置2.1 None、NaN、NaT、pd.NA 四者的檢測差異很多人以為缺失值只有一種其實 Pandas 里至少活躍著四種None、np.nan、pd.NaT、pd.NA。好消息是df.isna()和pd.isna()對這四種都能識別所以你日常用isna()做檢測基本不會漏。壞消息是它們的比較行為完全不同這會在條件篩選中給你埋雷。np.nan的經(jīng)典特性是它不等于自己np.nan np.nan返回False。這在寫篩選條件時非?？觗f[df[col] np.nan]永遠返回空表。同理df[col] ! np.nan也不是非缺失的意思它會返回全True。正確寫法只有df[df[col].isna()]和df[df[col].notna()]兩種別用等號。pd.NA是 Pandas 1.0 之后引入的標量缺失值配合Int64、boolean、string這些可空類型使用。它的比較行為更理性——pd.NA pd.NA返回的是pd.NA而不是True或False所以拿它做布爾判斷會直接拋異常val pd.NA if val: # TypeError: boolean value of NA is ambiguous pass這個報錯我第一次遇到時找了半天因為代碼邏輯看起來完全正常。根因是pd.NA參與布爾上下文時無法確定真假。規(guī)避辦法很簡單判斷缺失統(tǒng)一用pd.isna(val)不要寫if val。NaT是時間類型的缺失值行為和np.nan類似pd.NaT pd.NaT同樣是False。2.2 字符串形式的缺失和占位符真正讓我吃虧的是假缺失。從業(yè)務系統(tǒng)導出的 CSV 里缺失經(jīng)常長這樣空字符串、NULL、null、N/A、-、無、nan。這些在 Pandas 眼里都是合法的字符串isna()一個都不會報。你跑df.isna().sum()看到零缺失心里踏實了結果value_counts()一出來NULL排第三。這類問題必須在入口處解決不要留到填充階段。我的做法是在read_csv階段就把常見占位符注冊成缺失df pd.read_csv( orders.csv, na_values[, NULL, null, N/A, NA, -, 無, nan, NaN], keep_default_naTrue, )keep_default_naTrue是默認值它會把NaN、null、None這些常見標記一起識別掉一般不用動。但如果你業(yè)務里真的存在字符串NA比如某個地區(qū)代碼就是 NA那就得把它從na_values里拿掉或者用keep_default_naFalse然后手動列全。這個取舍必須做因為一旦把有效值誤判成缺失后面補回去的值就全是錯的。已經(jīng)在內(nèi)存里的 DataFrame 也有補救辦法df df.replace({: np.nan, NULL: np.nan, -: np.nan})replace會遍歷匹配列多的時候速度不快但勝在直觀。如果只針對某幾列寫成df[[col_a, col_b]].replace(...)再賦值回去會更快注意別漏掉賦值這一步replace默認不原地修改。2.3 用 dtype 反推缺失來源還有一個不太起眼的排查角度看 dtype。如果一列本該是整型結果dtypes顯示float64那幾乎可以確定里面混了NaN因為整型數(shù)組裝不下缺失值Pandas 會自動把它升成浮點。反過來一列object類型卻全是數(shù)字字符串說明導入時沒做類型推斷這時候用pd.to_numeric(errorscoerce)轉一遍轉換失敗的會變成NaN這本身就是一次缺失識別。df[amount] pd.to_numeric(df[amount], errorscoerce) # 轉換后 isna 數(shù)量變化的部分就是原來的臟值errorscoerce是關鍵參數(shù)默認的raise遇到臟值直接拋異常ignore則原樣返回不做轉換只有coerce會把無法解析的轉成缺失。這個寫法我在清洗金額、數(shù)量、評分這類字段時用得最多比正則匹配省事得多。3. fillna 的四種傳參姿勢以及 inplace 到底該不該用3.1 標量、字典、Series、method 的選擇邏輯fillna的參數(shù)類型決定了它的作用范圍選錯了會出現(xiàn)以為填了其實沒填或者填錯了列的情況。傳標量最直接df.fillna(0)會把全表所有缺失都換成 0。這個寫法在混合類型的表上非常危險因為字符串列也會被塞進數(shù)字 0整列 dtype 變成object后面做字符串操作時全是坑。除非你確認表里只有數(shù)值列否則不要這么寫。傳字典是精準控制的主力寫法鍵是列名值是該列的填充值df df.fillna({ amount: 0, category: 未知, score: df[score].median(), })字典里沒出現(xiàn)的列保持原樣這一點很關鍵——它意味著你可以只處理該處理的列剩下的留給后面的邏輯。我一般會先用一個字典把每列的填充策略寫清楚相當于把決策顯式記錄下來方便回看。傳 Series 適合每列一個不同的值且有計算邏輯的場景最常見的是用均值填充num_cols df.select_dtypes(includenumber).columns df[num_cols] df[num_cols].fillna(df[num_cols].mean())注意這里必須顯式選數(shù)值列。直接寫df.fillna(df.mean())在 Pandas 2.x 上會因為mean()遇到非數(shù)值列而報錯老版本則會靜默丟掉非數(shù)值列兩個版本行為不一致是個典型的版本遷移坑。method參數(shù)ffill、bfill在新版本里被標記為棄用Pandas 2.1 之后推薦直接用df.ffill()和df.bfill()。如果你維護的代碼要跨版本跑建議統(tǒng)一改成新寫法fillna(method...)雖然還能用但警告會一直刷屏。3.2 inplaceTrue 與鏈式賦值的那點事inplaceTrue看起來省事實際上是 Pandas 里最容易出問題的一類寫法。它的問題不在于功能而在于它不返回新對象所以不能參與鏈式調(diào)用# 這樣寫df 根本沒變 df.fillna(0, inplaceTrue) # 這樣寫會報錯因為 fillna 返回 None df df.fillna(0, inplaceTrue)第二種寫法是新手高頻錯誤賦值之后df變成None后面所有操作全部崩掉而且報錯信息往往出現(xiàn)在很遠的地方排查起來很費勁。更隱蔽的是視圖問題。如果你手上的df是從一個大表切出來的inplaceTrue可能觸發(fā)SettingWithCopyWarning甚至在某些情況下改的是副本而不是原表你以為改了其實沒改sub big_df[big_df[status] paid] sub.fillna(0, inplaceTrue) # 可能警告也可能不生效穩(wěn)妥的做法是永遠不用inplace改成顯式賦值并且在切片時加.copy()sub big_df[big_df[status] paid].copy() sub sub.fillna(0)多寫一行賦值能省掉后面半小時的排查時間這筆賬很劃算。我現(xiàn)在的習慣是項目里全局禁用inplaceTrue代碼審查時看到就打回去改。3.3 limit 和 axis前向填充的真正粒度ffill和bfill都支持limit參數(shù)用來限制連續(xù)填充的最大長度。這個參數(shù)在傳感器數(shù)據(jù)、日志流水場景里特別有用因為長時間斷檔往往意味著設備離線這時候繼續(xù)沿用最后一個值就是在編數(shù)據(jù)。# 最多連續(xù)補 3 個超過的保持缺失 df[sensor] df[sensor].ffill(limit3)axis參數(shù)決定填充方向。默認axis0是按行往下填也就是沿著索引方向axis1是按列往右填用同一行左邊的值補右邊的空。后者在寬表場景里有奇效比如每月一列的表想用上月值補本月空值就可以用axis1配合ffill。但這個操作對列順序極其敏感列一旦亂序補出來的值毫無意義用之前務必先排序并確認列序。還有一個limit_area參數(shù)inside表示只填充被有效值夾在中間的缺失outside表示只填充兩端的缺失。這個在時間序列里很實用因為首尾的缺失往往不能用插值補中間斷檔才是真正需要插的地方。4. interpolate 不是萬能膠插值方法的適用邊界4.1 線性插值、時間插值、索引插值的差別interpolate()的默認方法是linear它在缺失點的前后各找一個有效值按等距做線性過渡。這個等距指的是索引位置等距不是時間等距。如果你的數(shù)據(jù)是按天采集但中間跳過了周末索引不連續(xù)linear就會把周五到下周一當成一步補出來的值偏保守。methodtime解決的就是這個問題它按索引的實際時間間隔加權。前提是索引必須是DatetimeIndex否則直接報錯df df.set_index(date).sort_index() df[value] df[value].interpolate(methodtime)methodindex和values的區(qū)別在于前者用索引的數(shù)值做插值依據(jù)后者用實際數(shù)據(jù)的值做依據(jù)。日常用得最多的是time和默認的linear其余方法按需。這里有個容易被忽略的前提interpolate默認只填中間的缺失。如果缺失出現(xiàn)在序列開頭或結尾默認參數(shù)下它不會動你會看到isna().sum()還有殘留。要處理首尾就加limit_directionboth但加之前想清楚——首尾缺失沒有參照值補出來的其實是外推可信度要打折。4.2 多項式與樣條order 調(diào)大不等于更準methodpolynomial配合order參數(shù)可以做多項式擬合插值methodspline做樣條插值。這兩種方法看起來很高級實際使用限制很多。多項式要求有效點數(shù)量至少是order 1order3就意味著缺口兩側加起來至少要有 4 個有效值否則報錯。更麻煩的是高次多項式會出現(xiàn)龍格現(xiàn)象也就是在區(qū)間邊緣劇烈震蕩補出來的值可能遠超原始數(shù)據(jù)的取值范圍。我試過在一條平穩(wěn)的溫度曲線上用order5插值結果補出來的峰值比實際最高溫還高出好幾度這種結果拿去做告警閾值就是災難。樣條方法依賴scipy環(huán)境里沒裝會直接報ImportError這在容器化部署時是個常見的漏裝項。而且樣條同樣對噪聲敏感數(shù)據(jù)本身抖動大的時候插值曲線會跟著抖。我的判斷標準很簡單數(shù)據(jù)本身是平滑的物理量溫度、壓力、連續(xù)位移可以試試樣條數(shù)據(jù)是業(yè)務指標訂單量、訪問量老老實實用線性或前向填充。業(yè)務指標往往有突變和周期性任何平滑假設都不成立。4.3 limit_direction 與 limit_area 的配合這兩個參數(shù)經(jīng)常一起用配合不好會出現(xiàn)補了一半的情況。limit_direction控制方向forward、backward、bothlimit_area控制區(qū)域inside、outside、None。默認組合是forwardNone效果是只填中間的缺失首尾不動。一個實際的組合示例我想補中間斷檔但最多補 5 個且不動兩端filled df[value].interpolate( methodlinear, limit5, limit_directionforward, limit_areainside, )如果我想把兩端的缺失也用最近值補上就改成limit_directionboth并且limit_areaNone。這時候首尾會分別用bfill和ffill的效果填滿但要注意這是外推不是插值。4.4 非數(shù)值列與邊界缺失的處理interpolate只對數(shù)值列有效對object列調(diào)用會報TypeError。所以批量插值前一定要先篩列num_cols df.select_dtypes(includenumber).columns df[num_cols] df[num_cols].interpolate(methodlinear, limit_directionboth)另外一個邊界情況是整列全空或者只有一個有效值。全空列插值后還是全空這沒什么可說的只有一個有效值的列線性插值會把這個值鋪滿整列看起來補全了實際上是偽數(shù)據(jù)。這種情況我寧可保留缺失也不要制造一整列常數(shù)因為它會嚴重誤導后續(xù)的統(tǒng)計。5. 分組內(nèi)的前向填充groupby transform 的對齊陷阱5.1 為什么全表 ffill 會把上一個用戶的記錄帶過來這是我在真實項目里踩過最狠的一個坑。有張用戶行為表按用戶分組、按時間排序中間有些字段缺失我圖省事直接全表ffill()結果第一個用戶的最后一個值被帶到了第二個用戶的第一行。數(shù)據(jù)量大的時候這種污染是隱蔽的因為補出來的值看起來完全正常只有做用戶級別的聚合時才會發(fā)現(xiàn)某些用戶的初始狀態(tài)莫名其妙。根因很直接ffill()只看行的物理順序不知道分組這回事。它眼里只有上下行沒有用戶邊界。所以只要涉及多實體數(shù)據(jù)前向填充幾乎一定要配合分組。5.2 transform、apply、直接 groupby.ffill 三種寫法對比三種寫法我都用過效果有差異穩(wěn)定性也不同。第一種是直接調(diào)用df[val] df.groupby(user_id)[val].ffill()這是最簡潔的寫法Pandas 內(nèi)部會對每個分組做填充再拼回原索引對齊是正確的。我在 1.5 之后的版本里用這個沒出過問題。第二種是transform配合 lambdadf[val] df.groupby(user_id)[val].transform(lambda s: s.ffill())功能上和第一種等價但多了一層 Python 函數(shù)調(diào)用大數(shù)據(jù)量下會慢一些。它的優(yōu)勢是可以在 lambda 里塞更復雜的邏輯比如先判斷再填。第三種是applydf[val] df.groupby(user_id)[val].apply(lambda s: s.ffill())這個寫法要小心。apply在某些 Pandas 版本和某些分組結構下返回的索引層級不一樣直接賦值可能觸發(fā)索引對齊問題結果是整列變成NaN或者錯位。如果你非要用apply先reset_index(level0, dropTrue)把多余的分組層級去掉再賦值。我現(xiàn)在的默認選擇是第一種簡單、快、對齊可靠。只有在填充邏輯帶條件判斷時才退到transform。5.3 分組鍵本身缺失時會發(fā)生什么還有一個更隱蔽的坑如果分組鍵自己就有缺失值groupby默認會把這些行整個丟掉dropnaFalse才會保留。這意味著你按user_id分組填充user_id為空的那批行根本不在任何分組里填充結果對它們是NaN而且原表里這些行的其他字段也不會被處理。# 默認行為user_id 為 NaN 的行被排除在分組之外 df[val] df.groupby(user_id, dropnaFalse)[val].ffill()加上dropnaFalse之后缺失的分組鍵會單獨成一組填充邏輯才能覆蓋到它們。這個參數(shù)在 Pandas 1.1 之后才有如果你的環(huán)境版本較老就得先用一個占位符把user_id的空值替換掉再分組。5.4 多列同時分組填充的寫法實際業(yè)務里經(jīng)常需要按多個鍵分組比如按用戶 會話填充分組內(nèi)的字段keys [user_id, session_id] cols [device, channel] df[cols] df.groupby(keys, dropnaFalse)[cols].ffill()多列同時ffill時Pandas 會對每個分組內(nèi)的每一列獨立做前向填充互不干擾。但要注意如果某一行device有值而channel為空填充后的channel會取同一分組內(nèi)最近一次有值的記錄而不是取同一行的device。這個語義是對的但你得清楚自己在做什么。6. 填充之后的 dtype 變化與下游連鎖反應6.1 整型列被 NaN 拖成 float這是 Pandas 里最經(jīng)典的隱形變化。一個整數(shù)列只要出現(xiàn)一個NaN整列 dtype 就從int64變成float64因為 NumPy 的整型數(shù)組裝不下缺失值。這個變化不會報錯但會在下游引發(fā)一連串問題ID 列變成浮點后顯示成1.0跟字符串拼接時多出.0做主鍵關聯(lián)時1和1.0匹配不上導出 CSV 時整列多了小數(shù)點。s pd.Series([1, 2, None]) print(s.dtype) # float64規(guī)避方式有兩種。一是填充之后再轉回整型df[id] df[id].fillna(-1).astype(int64)前提是填充值本身是整數(shù)這里用 -1 做缺失標記。二是從一開始就用可空整型Int64df[id] df[id].astype(Int64)Int64注意大寫 I是 Pandas 的可空整型能同時裝整數(shù)和pd.NA不會被迫升成浮點。代價是它和其他庫的兼容性不如原生int64比如某些舊版的機器學習庫拿到Int64列會報錯需要顯式.astype(int64)或.to_numpy(dtypefloat64, na_valuenp.nan)轉換。6.2 用填充值當缺失標記時的一致性用-1或0這類哨兵值填充之后最大的風險是后續(xù)忘了這回事把它當成真實值參與計算。防止的辦法有兩個一是在填充的同時建一個標記列記錄哪些位置是補的二是在管道里約定哨兵值只在展示層出現(xiàn)計算前必須還原成 NaN。df[amount_missing] df[amount].isna() df[amount] df[amount].fillna(-1).astype(int64)標記列的好處是信息不丟代價是表變寬、需要維護。我一般只在關鍵指標列上加標記比如金額、等級、評分這幾個直接影響結論的字段普通描述性字段就不折騰了。6.3 填充結果的回歸校驗填充完一定要做一次校驗看看分布有沒有被改得離譜。最省事的做法是比對填充前后的描述統(tǒng)計before df_before[amount].describe() after df_after[amount].describe() print(pd.concat([before, after], axis1, keys[before, after]))重點看mean和std的偏移。用中位數(shù)填充時mean通常會往中位數(shù)方向靠std會明顯下降。如果偏移超過 10%說明缺失比例已經(jīng)不低填充本身在改變數(shù)據(jù)的面貌這時候應該在報告里顯式說明處理方式而不是悄悄補完了事。另外一個校驗角度是分位數(shù)。填充常量會讓某個分位點突然堆積大量相同值quantile([0.25, 0.5, 0.75])的結果里如果連續(xù)兩個分位點相等基本就是這個原因。7. 時間序列里的缺失重采樣、asfreq 與業(yè)務口徑7.1 resample 之后為什么憑空多出 NaNresample是按時間頻率重新組織數(shù)據(jù)如果原始數(shù)據(jù)在某些時間點上沒有記錄重采樣后的結果里這些位置就是NaN。這不是數(shù)據(jù)出錯而是頻率對齊的必然結果。比如原始數(shù)據(jù)只有工作日的記錄按自然日重采樣后周末兩天就會空出來。daily df.set_index(date).resample(D).agg({amount: sum})這里有個語義問題必須先想清楚周末沒有記錄到底應該補 0 還是保留NaN如果是每天銷售額這種口徑周末沒交易就是 0補 0 是對的如果是每天平均溫度這種口徑?jīng)]記錄就是沒測補 0 會把均值拉低應該保留缺失或做插值。選錯了整條曲線的形狀就變了。我一般的判斷標準是看指標的可加性?？杉又笜私痤~、次數(shù)、條數(shù)在時間維度上聚合時空檔期的合理值通常是 0不可加指標比率、均值、溫度、價格空檔期應該保持缺失用插值或前值更合理。7.2 asfreq 和 reindex 的補位邏輯asfreq是把索引轉換成指定頻率不涉及聚合純粹是補位。它的作用和reindex類似但更簡潔ts df.set_index(date)[amount] full ts.asfreq(D)asfreq之后可以用fill_value直接指定補位值full ts.asfreq(D, fill_value0)這個寫法比先asfreq再fillna(0)少一步語義也更清楚。但要注意fill_value只對新插入的位置生效原本就存在的NaN不會被它填充這一點很容易誤解。reindex的優(yōu)勢是可以指定完整的時間范圍包括原始數(shù)據(jù)里根本沒有的區(qū)間full_range pd.date_range(start2024-01-01, end2024-12-31, freqD) full ts.reindex(full_range)這個用法在做年度報表時很常見因為原始數(shù)據(jù)可能只覆蓋了部分月份而報表需要完整的 365 天。7.3 補位之后再做差分和同比的注意事項時間序列補完位很多人下一步就是做差分或者同比。這里有個細節(jié)差分前必須確保索引是連續(xù)的否則diff()會把不相鄰的兩個點當成相鄰算出來的差值沒有意義。asfreq或reindex之后索引就連續(xù)了但如果中間有重復索引結果還是會錯最好加一句ts ts[~ts.index.duplicated(keeplast)]去重。同比計算也是同理pct_change(periods365)依賴索引的等距性索引不連續(xù)時這個 365 就不是一年。穩(wěn)妥的做法是先把數(shù)據(jù)對齊到日頻并補齊再做位移計算。補位的值會影響同比結果用 0 補和用前值補同比數(shù)字能差出一大截這個口徑必須在做分析之前跟需求方確認清楚不能自己拍腦袋。7.4 重置索引前的最后一次檢查補位和填充做完重置索引之前我會跑一遍完整的檢查清單assert df.index.is_monotonic_increasing, 索引未排序 assert not df.index.has_duplicates, 索引有重復 print(df.isna().sum()[df.isna().sum() 0])第一句確保有序第二句確保無重復第三句列出仍有缺失的列。第三句的結果不一定是錯的——有些列本來就該保留缺失但你必須逐列確認過而不是默認應該都補完了。這個習慣幫我抓到過好幾次漏填的情況特別是那些在字典里寫錯了列名導致沒匹配上的填充規(guī)則。最后分享一個我在實際項目里的體會缺失值處理最難的不是寫代碼而是給每一個空位找到一個能說服自己的理由。fillna(0)只需要一秒但解釋為什么這里填 0 而不是中位數(shù)可能要花十分鐘。這十分鐘花得值因為它在后面每一次數(shù)據(jù)被質(zhì)疑的時候都能替你回答那個問題。我現(xiàn)在的習慣是在清洗腳本里給每個填充決策寫一行注釋寫清楚依據(jù)和影響范圍半年后回頭看這些注釋比腳本本身更有價值。