概述
Codegraph v1.6.1(2026-09-29)是一個「讓圖譜理解你的應用程式」的版本。這次的三大升級軸線:
- 導覽與請求進入圖譜:route 不再只是字串,而是節點;
router.push('/x')不再是死路,而是navigates邊。 - Flow 標示呼叫條件:每一跳帶著它發生的
if條件,AI 不再把「可能發生的呼叫」當成「一定發生的呼叫」。 - 更少錯誤連結:同名符號的誤連大量清除。
新增一:應用程式的導覽進入圖譜
支援的框架
| 框架 | route 來源 | 導覽邊來源 |
|---|---|---|
| Expo Router | app/(或 src/app/)下的 screen 檔案 |
router.push、router.navigate、template literal href |
| Next.js | App Router page.tsx + Pages Router |
<Link href>、router.push、redirect()、middleware NextResponse.redirect |
| React Router | <Route> 與 createRoute |
navigate()、history.push、<Link to>、loader 中的 redirect() |
| TanStack Router | file-based 與 code-based 兩種宣告 | navigate({ to })、thrown redirect、<Link to> |
| Vue Router / Nuxt | createRouter({ routes }) 含 lazy component |
router.push、navigateTo、<RouterLink>/<NuxtLink> |
| SvelteKit | +page.svelte(layout 與 error 頁不是 route) |
goto()、load/action 中的 redirect(303, …)、<a href> |
fetch 也連到 route
codegraph_explore 現在能跨層追蹤:一個頁面的 fetch('/api/users', { method: 'POST' })——或 axios / ky / got / $fetch 呼叫——在同一索引內可追溯到服務它的 route。「這個按鈕點了會去哪」與「誰呼叫這個 endpoint」變成同一個問題的兩面。
前端元件 後端 route
───────── ─────────
ProfilePage.tsx
│ fetch('/api/users') navigates/serve
├──────────────────────────────▶ GET /api/users (route.ts)
│ │
◀─── codegraph_explore 一次回傳 ──────┘
佇列、事件與 server action
- BullMQ / Bull:job 從
queue.add()連到消費它的@Process方法、Worker或queue.processhandler - NestJS EventEmitter2:
emit('x')連到@OnEvent('x')listener(雙向) - Socket:訊息連到 gateway 的
@SubscribeMessagehandler - Next.js server action:client 檔案的呼叫是跨越到 server 的邊
新增二:Flow 標示呼叫條件
v1.6.1 之前,codegraph_explore 的 Flow 段落只顯示「A 呼叫 B」。現在每一跳帶著它發生的條件:
collectData()
↓ calls (when isCollected)
persist()
↓ calls (when !isCollected)
logSkip()
條件讀取自呼叫點周圍的控制流:if/else、switch/when/match、三元、try、&& 分支,以及呼叫前的早期返回(if (busy) return 讀作 !busy;Go 的 if err != nil { return } 讀作 err == nil)。
支援語言:JavaScript、TypeScript、Swift、Python、Java、Kotlin、C#、Go 與 C。沒有規則的語言寧可不說也不猜。
在 v1.6.1 中,`codegraph_explore` 顯示 `↓ calls (when !busy)`,這代表什麼?
💡 想先看個提示?
想想 `if (busy) return;` 出現在呼叫前面時,什麼情況下才會走到呼叫那行。
if (busy) return 這種早期返回會被讀作 !busy——意思是「當不忙碌時才繼續執行到底下的呼叫」。它描述的是呼叫發生的前提,不是呼叫的結果,也不是錯誤。新增三:更少錯誤連結
這版修正了 10 種語言中呼叫、匯入與繼承的解析。三個代表性案例:
1. 同名 method 誤連:serialize(this.raw) 寫在 Record.serialize method 內——它呼叫的是 module-level 的 serialize() 函式,但舊版讓 method 自己呼叫了自己。JS/TS 中無 receiver 的呼叫永遠不會是 method,method 不再是候選。
2. 檔案私有符號的越權解析:C 的 static、Java/Kotlin 的 private、Rust 的非 pub——這些檔案私有定義不可能是其他檔案中同名的意思。修復後,名稱匹配管線結束後會拒絕這類目標,reference 保持 unresolved 而非落到模糊的同名者。
3. .js 匯入找不到 .ts 源:moduleResolution: node16 | nodenext | bundler 下 import { x } from './util.js' 指 util.ts,但該檔不存在、匯入解析返回空、名稱落入裸名匹配的猜測。修復後 .js/.jsx/.mjs/.cjs specifier 會以 TypeScript 編譯來源副檔名重試——實測 582 檔專案的 import-backed 邊從 4,002 升到 7,312,8 個 wrapper-method 自我呼叫邊消失。
探索答案品質
- 指定的函式與方法完整回傳——即使來自超大檔案或滿是同名 override 的檔案
- 遵守行號:
compiler.py:776回傳含該行的 method;lines 900-1003回傳確切行段 - 被縮短時明說:答案不再謊稱完整,會列出被修剪的檔案與省略的函式,並給出取回完整內容的後續查詢
- 中文檔名查詢(含或不含副檔名)可找到檔案
同步與大型儲存庫
- MCP server 在
codegraph index後切換到重建的索引並補趕錯過的變更 - 中斷的 sync 恢復到與乾淨索引相同的連線(含繼承呼叫與 callback)
- symlink 目錄內的編輯在 macOS / Windows / Linux 自動同步
- WSL 掛載 Windows 磁碟(
/mnt/c/…)的專案取得獨立的.codegraph-wsl/索引——Windows 與 WSL 不再共用一個索引而互相搞壞 - 重複的 explore 呼叫不再重掃整個圖譜;偽
.ts的影片 fixture 不再被送進 TypeScript parser
隨堂總結測驗
小美升級 Codegraph 到 v1.6.1 後直接開始工作(沒有重新索引),她查 `codegraph_explore` 問「誰呼叫這個 Express route」,最可能發生什麼?
💡 想先看個提示?
回顧開頭的「升級前必看」提示框。
codegraph status 會提醒你重新索引,但查詢不會自動觸發重建。動手升級檢查清單
升級 v1.6.1:動手檢查清單
逐項勾選,確認你已完成升級必要的步驟(進度會保存在此瀏覽器)
延伸閱讀
-
下一課:
initializing-and-syncing——索引的初始化與即時同步機制 -
版本紀錄:本主題的 Changelog 頁有完整的 v1.6.1 條目