上一篇我整理了 5 類項目規則其中一條是修改公共組件、公共契約或狀態來源之前先查調用方和兼容影響。這句話寫進規則不難真正執行時卻很容易被簡化成搜索一下組件名看看哪些文件導入了它。這只能查到調用鏈的一部分。前端組件不是一個只被import的函數。它可能通過全局注冊使用通過路由或動態組件加載通過包裝組件再次暴露它與父級之間還存在 Props、Emits、v-model、插槽和暴露方法。組件內部又可能讀寫狀態、發請求、改路由、操作緩存甚至依賴特定 DOM 結構和外部樣式。只找到“誰引用了這個組件”還不足以回答真正重要的問題誰依賴了它的哪一項行為哪些依賴在類型層面可見哪些只在運行時出現組件的輸出被誰繼續消費某個默認行為改變后會在哪條用戶路徑上暴露哪些檢查可以證明調用方沒有被破壞所以我讓 Codex 修改組件前查的不是一份引用列表而是一條行為調用鏈。調用鏈不是“誰導入了誰”而是行為怎樣穿過邊界我會把前端組件調用鏈寫成下面這條路徑用戶入口 → 頁面或容器 → 組件輸入 → 組件內部狀態與副作用 → 組件輸出 → 調用方后續動作 → 頁面結果其中任何一段發生變化都可能讓一個局部修改擴散出去。例如一個編輯彈窗保存成功后觸發事件。單看彈窗文件可能只是這樣一條輸出保存成功 → 觸發 saved 事件放進完整鏈路后真實行為可能是列表頁點擊編輯 → 傳入當前記錄標識 → 彈窗請求詳情并回填 → 用戶提交 → 彈窗調用保存接口 → 觸發 saved 事件 → 父頁面關閉彈窗 → 保留當前篩選條件刷新列表 → 必要時調整當前頁碼如果只修改事件名稱或關閉邏輯后面的刷新、頁碼和篩選狀態都可能受影響。這就是“組件文件只改了幾行頁面行為卻變了”的來源。第一個誤區搜索組件名就認為找到了全部調用方名稱搜索很有用但它默認只能找到文本中可見的引用。下面這些情況很容易漏掉經過統一出口再次導出業務文件可能不是直接導入目標組件而是從組件庫入口、模塊索引或別名路徑導入。經過包裝組件使用頁面使用的是BusinessDialog真正修改的是內部的BaseDialog。直接搜索目標組件只會找到包裝層真正依賴默認行為的是更上層頁面。全局注冊模板中直接使用組件標簽沒有本地導入。名稱映射可能發生在應用入口或自動導入配置中。動態組件組件由配置、映射表或字符串名稱決定。靜態搜索可能只找到注冊表找不到真實業務路徑。路由或文件掃描頁面組件可能由路由生成、模塊掃描或約定式目錄自動接入文件中沒有一條直觀的手寫引用。所以第一輪搜索得到的是“候選調用方”還需要沿導出、注冊、包裝和入口關系繼續向上確認。我會要求 Codex 給每個調用方標注發現方式直接導入、二次導出、包裝、全局注冊、動態映射或路由入口。這樣能看出哪些結論可靠哪些仍需要運行路徑驗證。第二個誤區只查組件文件不查它的公開契約組件調用鏈的核心是公開契約。我至少會讓 Codex 檢查 5 個位置。Props不只看屬性名稱還要看是否必填默認值是什么是否允許對象被組件內部修改父級傳入的是原始狀態、計算結果還是臨時副本多個屬性之間是否存在隱含組合規則。把一個可選 Prop 改成必填類型檢查可能暴露部分影響改變默認值則可能悄悄改變所有沒有顯式傳值的調用方。Emits 與v-model要查事件名稱、觸發時機、事件負載和消費方式。同一個事件可能被不同頁面用于關閉彈窗刷新列表更新本地對象觸發下一步流程記錄操作結果。如果只確認“父級監聽了事件”仍然不知道事件行為變化會影響什么。插槽插槽依賴往往不容易通過類型和普通引用搜索發現。調用方可能依賴具名插槽是否存在插槽作用域暴露哪些數據DOM 包裹層級空插槽時的默認內容插槽渲染順序。刪除一層容器看似只是模板整理可能破壞插槽布局或外部樣式。暴露方法與組件引用父級可能通過組件引用調用open、reset、validate或其他方法。這類依賴未必出現在 Props 和 Emits 定義中。修改方法簽名、返回值或調用時機需要查所有組件引用和類型聲明。透傳屬性與原生事件一些組件會把未聲明屬性、類名或事件繼續傳給內部節點。調用方依賴的行為可能沒有被組件 API 明確寫出卻在頁面中真實存在。公開契約查完后我才知道組件修改是內部實現變化還是已經觸碰外部行為。第三個誤區只向上找調用方不向下查狀態和副作用調用鏈有兩個方向向上誰使用組件、怎樣消費它的輸出向下組件依賴什么狀態、請求、路由和公共能力。很多影響并不來自組件 API而來自內部副作用。例如組件可能打開時請求詳情寫入共享狀態修改路由查詢參數更新瀏覽器緩存訂閱全局事件注冊定時器觸發埋點或日志在卸載時清理資源。如果修改初始化時機受影響的可能不只是當前頁面還包括共享狀態的其他消費者如果把請求從打開時改到首次掛載緩存頁面和重復打開路徑可能出現不同結果。我會讓 Codex 為每個副作用回答四個問題誰觸發它它讀寫什么外部狀態成功、失敗和取消時分別怎樣收尾還有誰會觀察到這次變化。這一步能把“組件內部重構”中隱藏的全局影響暴露出來。第四個誤區忽略生命周期和調用順序同一組函數執行順序不同行為可能完全不同。前端組件里需要特別檢查首次掛載每次打開Props 變化路由切換緩存激活與失活彈窗關閉組件卸載異步請求返回。例如父級先更新記錄 ID再打開彈窗組件可能監聽 ID 變化請求詳情也可能在打開動作中讀取 ID。如果 Codex 只看到兩段邏輯都存在就可能把它們合并成一個更“簡潔”的初始化函數卻改變了調用順序。調用順序還會影響舊請求是否覆蓋新對象校驗信息何時清除Loading 是否在關閉后繼續默認值是否在回填后被重置父級刷新是否發生在彈窗關閉前后。所以調用鏈不能只畫靜態箭頭還要標記關鍵時間點。第五個誤區DOM 和樣式沒有 import就不算依賴組件模板改變經常會產生代碼搜索難以發現的影響。調用方或全局樣式可能依賴特定類名子元素層級第幾個子元素深層選擇器組件根節點屬性透傳位置固定尺寸或溢出行為。測試也可能依賴文本內容標簽語義data-*標記可訪問名稱DOM 查詢路徑截圖基線。因此“只改模板結構不改功能”不代表影響范圍小。我會把樣式、測試、故事、示例和文檔視為組件的外圍消費者。它們不一定全部要修改但必須進入檢查范圍。我讓 Codex 查調用鏈的實際順序第一步先寫清準備改變什么調用鏈范圍取決于改動類型。“修改內部變量名”和“改變默認關閉行為”需要查的范圍完全不同。開始前先寫一條變化聲明準備改變 - 哪個可觀察行為或公開契約 - 保持不變的行為 - 當前認為是內部實現的部分如果連變化是什么都說不清搜索會無限擴散。第二步列出組件全部公開面包括 Props、Emits、v-model、插槽、暴露方法、屬性透傳、根節點和公開類型。這一步得到“可能傳播影響的出口”。第三步查組件怎樣進入項目沿直接導入、統一導出、包裝組件、全局注冊、動態映射、路由和自動掃描確認真實入口。這一步得到“誰可能使用它”。第四步逐個查看調用方怎樣依賴不能只記錄文件名要記錄使用的契約和依賴的行為調用方使用方式依賴內容變化后風險頁面 A直接使用Prop 默認值、保存事件可能改變刷新時機包裝組件 B二次封裝插槽與暴露方法可能繼續影響上層頁面動態入口 C配置映射組件名稱與屬性透傳需要運行時確認第五步向下追蹤狀態和副作用確認請求、狀態、路由、緩存、全局事件和生命周期清理。這一步得到“組件會改變什么外部狀態”。第六步補查外圍依賴包括樣式、測試、故事、示例、文檔和類型使用。第七步把未知項變成暫停條件例如動態組件入口無法靜態確認插槽作用域存在未聲明使用兩個調用方依賴相反的默認行為公共類型被其他應用復用頁面驗證環境無法啟動。未知項沒有解決前不應該讓 Codex 假設“其他調用方不受影響”。我會要求一份“調用鏈交付物”# 組件調用鏈檢查 ? ## 1. 計劃變化 - 要改變的行為或契約 - 必須保持不變 ? ## 2. 組件公開面 - Props - Emits / v-model - 插槽 - 暴露方法 - 透傳與根節點 - 公開類型 ? ## 3. 進入路徑 - 直接導入 - 統一導出或包裝 - 全局注冊 - 動態組件、路由或自動掃描 ? ## 4. 調用方 | 調用方 | 使用契約 | 依賴行為 | 影響類型 | 驗證方式 | | --- | --- | --- | --- | --- | ? ## 5. 下游依賴 - 狀態 - 請求 - 路由 - 緩存與全局事件 - 生命周期清理 ? ## 6. 外圍依賴 - 樣式 - 測試 - 示例與文檔 ? ## 7. 結論 - 直接影響 - 間接影響 - 條件性影響 - 尚未確認 - 是否可以進入修改計劃這份交付物不應該退化成幾十個文件名。每個文件都要說明它通過哪條契約或行為與組件發生關系。直接、間接和條件性影響要分開直接影響調用方明確使用了即將變化的 Prop、事件、插槽或方法。間接影響調用方使用包裝組件、共享狀態或公共類型變化經過中間層傳播。條件性影響只有特定路由、權限、配置、環境、數據或操作順序下才出現。三種影響的驗證方式不同。直接影響適合類型檢查和目標頁面回歸間接影響需要沿包裝與狀態繼續追蹤條件性影響則必須寫清觸發條件不能用一次正常路徑代替。哪些情況下可以停止繼續查調用鏈也不能無限擴張。我通常在下面幾個條件成立時停止組件所有公開面已經列清每個入口都能對應到真實調用方或明確排除計劃變化能映射到具體依賴行為狀態、副作用和生命周期責任已經定位樣式與測試的關鍵依賴已檢查每類影響都有驗證出口剩余未知不會改變實現方向或已明確標成后續人工驗證。目標不是理解整個項目而是證明當前改動不會越過尚未看見的責任邊界。寫在最后修改前查調用鏈不是為了生成一份漂亮的依賴圖而是為了回答三個問題這個組件的哪些行為對外構成契約誰直接、間接或在特定條件下依賴這些行為修改以后分別用什么證據證明調用方仍然成立。僅搜索組件名最多找到部分靜態入口。真正的調用鏈還包括 Props、Emits、v-model、插槽、暴露方法、狀態、副作用、生命周期、DOM、樣式和測試。下一篇我會把這份調用鏈進一步轉成影響范圍評估表怎樣區分內部實現、公開契約和用戶行為變化怎樣確定需要修改與只需回歸的位置以及怎樣據此調整 Codex 的執行批次和驗收路徑。本系列持續更新。接下來會從“找到依賴”進入“判斷影響”為后面的代碼差異審查建立一條清楚的基線。每日好工具推薦在這里推薦一款超好用的圖片壓縮工具——“圖壓”在線圖片壓縮免費壓縮 JPG、PNG、WebP - 圖壓工具。同事安利給我的用過后真的覺得太香了支持批量壓縮、調整壓縮百分比最關鍵的是它是離線程序下載到本地就能反復用。我平時做自媒體和寫前端時經常用到再也不用去網上找在線壓縮工具了。它也帶在線壓縮功能很方便。