TypeScript 的類型系統可以在程式碼運行前捕獲到相當一部分重要的 bug，例如類型不匹配、屬性缺失和函數簽名錯誤。但它無法捕捉其他所有問題：依賴應用程式資料流的安全漏洞、隨著團隊邊界模糊而逐漸累積的架構違規、呼叫者移除後仍然留在程式碼庫中的失效導出，以及編譯正確但在特定運行時條件下會失敗的非同步程式設計錯誤。靜態分析工具可以彌補這些不足，而選擇合適的工具組合則取決於您實際想要尋找的問題。
本指南涵蓋了 2026 年 TypeScript 團隊需要關注的工具：程式碼檢查層（ESLint 及其 typescript-eslint、Biome、OxcLint）、安全層（Semgrep、Snyk Code、SonarQube）、架構層（Dependency-Cruiser、Deptract、Nx）、死程式碼層分析器本身（Kipn）。對於每種工具，本指南都將重點放在其功能、配置方法以及不適用的情況。
TypeScript靜態分析工具：比較表
在深入探討各個工具之前，下表列出了每個工具的主要功能、持續整合適用性和理想使用情境。沒有任何一個工具能夠涵蓋所有方面，有效的 TypeScript 品質分析需要多種工具協同工作。
| 工具 | 主要功能 | CI適用 | 價格 | 最適合 |
|---|---|---|---|---|
| ESLint + typescript-eslint | 程式碼檢查、樣式、型別感知規則 | 可以 | 免費 | 團隊範圍內的約定、非同步類型安全 |
| 生物群系 | 程式碼檢查和格式化 | 可以 | 免費 | ESLint + Prettier 替代方案，速度更快 |
| 奧克林特 | 程式碼檢查（相容 ESLint） | 可以 | 免費 | Monorepo 需要快速的 lint 檢查時間 |
| TypeScript 編譯器 (tsc) | 類型檢查 | 可以 | 免費 | 類型錯誤，嚴格模式強制執行 |
| 塞姆格雷普 | SAST，自訂模式 | 可以 | 免費 + 付費 | 安全掃描、自訂組織規則 |
| Snyk 程式碼 | SAST、依賴安全 | 可以 | 免費 + 付費 | 安全至上的團隊，IDE 集成 |
| SonarQube / SonarCloud | 品質關口，趨勢跟踪 | 可以 | 免費 + 付費 | 企業品質儀錶板 |
| 聲納皮棉 | IDE級品質回饋 | 僅限 IDE | 免費 | 線上安全性和品質提示 |
| 依賴巡洋艦 | 依賴關係圖強制執行 | 可以 | 免費 | 架構規則驗證 |
| 部門 | 層邊界強制執行 | 可以 | 免費 | 清晰架構，領域驅動設計邊界 |
| Nx | Monorepo 依賴管理 | 可以 | 免費 + 付費 | Monorepo 模組邊界 |
| 剪刀 | 死程式碼和未使用的匯出 | 可以 | 免費 | 大規模減少未使用的程式碼 |
| ts-變形 | 程序化TS AST分析 | 選擇性 | 免費 | 自訂分析、程式碼轉換、工具 |
第一層：除毛和定型
使用 typescript-eslint 的 ESLint
ESLint 仍然是 TypeScript 程式碼檢查的基礎。 typescript-eslint 套件可以存取 TypeScript 的類型信息，並強制執行需要類型上下文的規則，其中最有價值的是針對非同步的特定規則，可以捕獲常見的 Promise 錯誤。
打壞
npm install --save-dev typescript-eslintJavaScript的
// eslint.config.js
import tseslint from "typescript-eslint";
export default tseslint.config(
...tseslint.configs.strictTypeChecked,
{
languageOptions: {
parserOptions: {
project: true,
tsconfigRootDir: import.meta.dirname,
},
},
rules: {
// Async safety rules -- highest value TypeScript-specific rules
"@typescript-eslint/no-floating-promises": "error",
"@typescript-eslint/await-thenable": "error",
"@typescript-eslint/no-misused-promises": "error",
"@typescript-eslint/require-await": "warn",
// Type safety
"@typescript-eslint/no-explicit-any": "warn",
"@typescript-eslint/no-unsafe-assignment": "error",
"@typescript-eslint/no-unsafe-return": "error",
},
}
);以上四條非同步規則是 typescript-eslint 相對於普通 ESLint 最有價值的補充。它們可以捕獲：未處理的 Promise（浮動 Promise）， await 適用於非 Promise 值、傳遞給期望同步函數的回呼函數的 Promise，以及從未使用的非同步函數。 await這些模式編譯時沒有問題，但在特定條件下會產生執行階段錯誤。
ESLint 無法做到的事文件間資料流分析、架構邊界強制執行、安全污點追蹤或失效匯出偵測。這些功能需要以下其他層的支援。
Biome：現代 ESLint + Prettier 的替代品
Biome 以一個基於 Rust 的二進位檔案取代了 ESLint 和 Prettier，運行速度提升 25-35 倍。它支援 JavaScript、TypeScript、JSX 和 JSON。對於那些因 ESLint 外掛程式的複雜性和在大程式碼庫中運行緩慢而感到沮喪的新專案或團隊來說，Biome 是目前最強大的替代方案。
打壞
npm install --save-dev --save-exact @biomejs/biome
npx @biomejs/biome init打壞
# Check and format in one pass
npx @biomejs/biome check --write src/
# CI mode -- no modifications, exit non-zero on any finding
npx @biomejs/biome ci src/Biome 的插件生態系統比 ESLint 的要小，這對於擁有大量自訂規則或框架特定插件的團隊來說至關重要。而對於僅使用核心 ESLint 規則和 Prettier 格式化的團隊來說，Biome 可以在執行時間更短的情況下提供同等的覆蓋率。
OxcLint：速度優先的 ESLint 相容性
OxcLint（Oxc 專案的一部分）運行與 ESLint 相容的規則速度比 ESLint 快 50-100 倍。它並不能取代完整的 ESLint 生態系統，但對於 CI 管線中 lint 檢查時間成為瓶頸的情況，它是最快的選擇。
打壞
npm install --save-dev oxlint
npx oxlint src/對於大型單體倉庫而言，OxcLint 是理想之選。在大型單體倉庫中，標準的 ESLint 耗時數分鐘，回饋循環的延遲會降低拉取請求的品質。 OxcLint 最好與 ESLint 一起使用，而不是取代它。在合併前階段，執行 OxcLint 以獲得快速回饋，而執行 ESLint 則可確保規則的全面覆蓋。
第二層：型別檢查，TypeScript 編譯器
TypeScript 編譯器（tsc它不僅僅是一個建構工具，它也是用於類型級正確性的主要靜態分析引擎。啟用嚴格模式會啟動能夠捕捉大多數實際應用中錯誤的設定：
JSON
{
"compilerOptions": {
"strict": true,
"noUnusedLocals": true,
"noUnusedParameters": true,
"noImplicitReturns": true,
"noFallthroughCasesInSwitch": true,
"exactOptionalPropertyTypes": true,
"useUnknownInCatchVariables": true
}
}打壞
# Type-check only, no emit -- ideal for CI
npx tsc --noEmitnoUnusedLocals 以及 noUnusedParameters 在編譯器層級擷取未使用的變數和函數參數。 useUnknownInCatchVariables （TypeScript 4.4+）類型擷取異常 unknown 而非 any強制在使用前進行明確類型縮小。
TypeScript 控制流程分析 這是編譯器提供的內建功能，用於在條件分支中縮小類型範圍。它不是一個單獨的工具。 strict 此模式確保它得到完全嚴格的應用。編譯器的控制流程分析能夠理解類型保護。 typeof 檢查， instanceof並區分了工會模式。
tsc限制TypeScript 編譯器不會尋找安全漏洞、架構邊界違規或失效匯出。它只會查找類型錯誤，而且會明確指出錯誤所在。
第 3 層：安全性，TypeScript 的 SAST
Semgrep：基於模式的安全掃描
Semgrep 透過程式碼模式匹配來發現安全漏洞。對於 TypeScript，它可以偵測 SQL 注入、XSS、硬編碼憑證和不安全程式碼。 eval 使用方式、原型污染和不安全的 Express.js 配置，這些模式雖然編譯正確，但會引入可利用的漏洞。
雅姆
# Custom rule: flag user input in SQL queries (TypeScript)
rules:
- id: ts-sql-injection-risk
patterns:
- pattern: |
const query = `SELECT ... ${$USER_INPUT} ...`;
message: "User input directly interpolated into SQL -- use parameterized queries"
languages: [typescript]
severity: ERROR打壞
# Run with the community TypeScript security rules
semgrep scan --config=p/typescript --config=p/owasp-top-ten src/Semgrep 與 ESLint 是互補關係，而非競爭關係。 ESLint 強制執行規範；Semgrep 則用於發現安全反模式。大多數重視安全性的 TypeScript 團隊都應該同時執行這兩個工具。
Snyk Code：基於機器學習的靜態應用安全測試 (SAST)，整合於 IDE
Snyk Code 使用基於機器學習的分析引擎執行靜態應用安全測試 (SAST)，該引擎可追蹤跨檔案的污點流。它整合到 VS Code 和 JetBrains IDE 中，可在開發人員編寫程式碼時直接顯示測試結果，而無需等待持續整合 (CI) 運行。
打壞
npm install --save-dev snyk
npx snyk auth
npx snyk code testSnyk Code 專注於開發者體驗，提供 IDE 內聯回饋、針對每個發現的修復建議以及補救範例，因此當安全教育與安全檢測同等重要時，它是更好的選擇。
SonarQube 和 SonarLint：品質門控和趨勢跟踪
SonarQube 提供持續的程式碼品質分析，包括儀錶板、趨勢追蹤和拉取請求標記。對於 TypeScript，它可以偵測錯誤、程式碼異味、安全漏洞和重複程式碼。 SonarLint 是一個 IDE 擴展，用於在本機上顯示 SonarQube 的規則。
對於 TypeScript 團隊來說，SonarCloud（雲端託管版本）是更簡單的選擇：對公用儲存庫免費，並且可以透過 GitHub Actions 或 GitLab CI 在幾分鐘內整合 CI。
雅姆
# .github/workflows/sonar.yml
- name: SonarCloud Scan
uses: SonarSource/sonarcloud-github-action@master
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}SonarQube 相較於原始程式碼檢查工具的主要價值在於其趨勢模型：程式碼品質如何隨時間演變，哪些元件正在退化，以及每個拉取請求的新程式碼品質閘控分數是多少。這些以管理階層為導向的指標正是 SonarQube 能夠做到而 ESLint 和 Semgrep 無法做到的。
第四層：架構分析
Dependency-Cruiser：強制執行模組邊界規則
Dependency-Cruiser 會驗證您的匯入圖是否符合定義的架構規則。它會產生可視化的依賴關係圖，並在程式碼違反模組邊界約束時導致持續整合失敗。
JavaScript的
// .dependency-cruiser.cjs
module.exports = {
forbidden: [
{
name: "no-circular",
severity: "error",
comment: "Circular dependencies make code hard to test and maintain",
from: {},
to: { circular: true },
},
{
name: "no-ui-in-domain",
severity: "error",
comment: "Domain modules must not import from UI layer",
from: { path: "^src/domain" },
to: { path: "^src/ui" },
},
{
name: "no-external-in-shared",
severity: "warn",
comment: "Shared utilities should minimize external dependencies",
from: { path: "^src/shared" },
to: { pathNot: "^(src|node_modules/(lodash|date-fns))" },
},
],
};打壞
npx depcruise --validate .dependency-cruiser.cjs src/Dependency-Cruiser 直接處理 Search Console 資料中的「react dependency analysis cli tool」查詢，它是 TypeScript/React 專案中產生和驗證依賴關係圖的標準工具。
Deptrac：基於層的邊界強制執行
Deptrac 強制執行架構層，確保持久化程式碼無法從表示層匯入，領域物件不依賴基礎架構，並且在整個程式碼庫中尊重模組邊界。
雅姆
# deptrac.yaml
parameters:
layers:
- name: Domain
collectors:
- type: directory
value: src/domain
- name: Application
collectors:
- type: directory
value: src/application
- name: Infrastructure
collectors:
- type: directory
value: src/infrastructure
ruleset:
Domain:
- ~Infrastructure # Domain must not depend on Infrastructure
Application:
- Domain
Infrastructure:
- Application
- DomainDeptrac 在遵循 Clean Architecture、DDD 或 Hexagonal Architecture 模式的專案中最為有價值，在這些專案中，層隔離是設計約束，而不僅僅是一種偏好。
Nx：單體倉庫層級依賴管理
對於 TypeScript monorepos，Nx 提供模組邊界強制執行、受影響的建置偵測以及儲存庫中所有專案的依賴關係圖視覺化。
JSON
// .eslintrc.json -- Nx module boundary rules
{
"rules": {
"@nx/enforce-module-boundaries": [
"error",
{
"allow": [],
"depConstraints": [
{ "sourceTag": "scope:shared", "onlyDependOnLibsWithTags": ["scope:shared"] },
{ "sourceTag": "scope:feature", "onlyDependOnLibsWithTags": ["scope:shared", "scope:feature"] },
{ "sourceTag": "scope:app", "onlyDependOnLibsWithTags": ["scope:shared", "scope:feature"] }
]
}
]
}
}Nx的 affected 命令僅執行與已更改模組相關的測試和程式碼檢查，從而顯著減少大型單體倉庫的 CI 時間。
第五層：死代碼偵測
Knip：尋找未使用的匯出、檔案和依賴項
Knip 分析完整的模組圖，以識別未使用的導出項、未使用的檔案和未使用的模組。 package.json 依賴項，即 ESLint 所收集的程式碼累積類別 no-unused-vars 無法捕獲，因為它只在文件內部查找。
打壞
npm install --save-dev knip
npx knipJSON
// knip.json
{
"entry": ["src/index.ts", "src/**/*.test.ts"],
"project": ["src/**/*.ts"],
"ignore": ["src/generated/**"],
"ignoreDependencies": ["vitest"]
}Knip 可以直接在 SC 資料中搜尋「死程式碼偵測未使用匯出 javascript typescript」。它是目前功能最強大的 TypeScript 專案模組級死代碼識別工具。
第 6 層：程序分析，ts-morph
ts-morph 是一個 TypeScript 編譯器 API 封裝器，它使得針對 TypeScript AST 編寫自訂分析、程式碼轉換和工具變得非常簡單。它會在 SC 資料中直接以「ts-morph」和「ts morph」的形式被搜尋。
打字稿
import { Project } from "ts-morph";
const project = new Project({ tsConfigFilePath: "tsconfig.json" });
// Find all async functions that never await anything
const suspiciousAsyncFns: string[] = [];
for (const sourceFile of project.getSourceFiles()) {
for (const fn of sourceFile.getFunctions()) {
if (fn.isAsync()) {
const hasAwait = fn.getDescendantsOfKind(
SyntaxKind.AwaitExpression
).length > 0;
if (!hasAwait) {
suspiciousAsyncFns.push(
`${sourceFile.getFilePath()}:${fn.getName() ?? "anonymous"}`
);
}
}
}
}
console.log("Async functions with no await:", suspiciousAsyncFns);ts-morph 並非現成的分析工具，而是用來建構分析工具的函式庫。它適用於需要超出現有工具支援範圍的自訂分析的團隊，例如：遷移腳本、自訂架構驗證器、自動化重構或程式碼生成管道。
TypeScript Async/await 靜態分析
Search Console 資料顯示，圍繞著「typescript static analysis async await paper tool」和「typescript static analysis async await vulnerability paper tool」的特定查詢集群。這反映出從業人員正在尋找能夠從類型層面理解非同步程式設計錯誤的工具。
對於生產環境中的 TypeScript 團隊來說，切實可行的解決方案是使用 typescript-eslint 的四個非同步特定規則（no-floating-promises, await-thenable, no-misused-promises, require-await）與 strictNullChecks 以及 useUnknownInCatchVariables這些方法結合起來，無需借助學術研究工具，就能捕捉最常見的非同步類型錯誤。
對於從事非同步漏洞模式安全研究的團隊來說，TAJS 和 Jelly 是模擬 JavaScript 非同步執行語意的學術靜態分析器，但它們是研究工具，而不是生產開發工具。
Angular 和 React：框架特定的靜態分析
對於 Angular 團隊, @angular-eslint 提供 Angular 特有的程式碼檢查規則，涵蓋元件模式、模板分析和服務注入。它與上述 ESLint + typescript-eslint 配置整合。
對於 React 團隊， eslint-plugin-react, eslint-plugin-react-hooks以及 eslint-plugin-jsx-a11y 插件涵蓋了 React 特有的模式。 Dependency-Cruiser 負責 React 特有的依賴關係圖分析，並且是 SC 資料中「react dependency analysis cli tool」查詢背後的工具。
IDE 整合：適用於 VS Code 和 JetBrains 的工具
「適用於 VS Code 整合的最佳程式碼品質工具」和「適用於 IDE 整合的最佳程式碼品質工具」這兩個搜尋字詞反映了一個實際需求：持續整合 (CI) 回饋來得太晚，無法及時改變行為。而整合到 IDE 中的分析則能提供最緊密的回饋循環。
VS代碼：ESLint 擴充功能與 rust-analyzer Clippy 功能相同，SonarLint 擴充功能用於內嵌 SonarQube 規則，Snyk 擴充功能用於安全發現，以及內建的 TypeScript 語言服務用於型別級回饋。
JetBrains（WebStorm/IntelliJ）WebStorm 內建了 TypeScript 支持，可以內嵌顯示類型錯誤，並整合了 ESLint、Prettier 和 SonarLint。其內建的檢查系統涵蓋了許多與 ESLint 規則相同的模式。
VS Code 配置以實現最大的 TypeScript 靜態分析覆蓋率:
JSON
// .vscode/settings.json
{
"typescript.tsdk": "node_modules/typescript/lib",
"typescript.enablePromptUseWorkspaceTsdk": true,
"editor.codeActionsOnSave": {
"source.fixAll.eslint": "explicit"
},
"eslint.validate": ["javascript", "typescript", "typescriptreact"],
"sonarlint.connectedMode.project": {
"connectionId": "my-sonarcloud",
"projectKey": "my-org_my-project"
}
}SMART TS XL 擴展企業範圍內的 TypeScript 分析
上述工具適用於 TypeScript 專案內部的 TypeScript 程式碼。但在 TypeScript 服務需要與 COBOL 批次程式、Java API、Python 資料管道或傳統大型主機系統互動的組織中，單語言工具無法辨識跨語言的依賴關係。
SMART TS XL“ 靜態程式碼分析 它涵蓋了 TypeScript 以及企業環境中的所有其他語言，包括 COBOL、JCL、Java、Python、RPG 和 SQL，並建立了一個跨所有這些語言的統一依賴模型。當 TypeScript 服務呼叫由 COBOL 程式支援的 API 時， SMART TS XL 可以追溯這種關係並將其納入其中 影響分析 在對任一元件進行任何變更之前。
这 企業搜索 此功能可讓整個多語言程式碼庫查詢：在幾秒鐘內，即可找到特定模組的每個 TypeScript 匯入、TypeScript 服務呼叫的每個 Java 方法、向 TypeScript 使用的 API 提供資料的每個 COBOL 副本，涵蓋數百萬行程式碼，支援任何語言組合。
對於將 TypeScript 作為大型技術組合中的一種語言來使用的企業團隊而言， SMART TS XL 提供架構可見性和跨語言 依賴映射 這使得 TypeScript 特有的工具能夠查看它們在系統中的部分，同時 SMART TS XL 看到全局。
建構合適的技術棧
沒有哪一款工具能夠涵蓋 TypeScript 的所有品質維度。正確的方法是分層式的，每一層都針對一類不同的問題：
最小可行堆疊 （新項目，小團隊）：
- TypeScript 嚴格模式
- 使用 typescript-eslint 非同步規則的 ESLint
npm audit依賴性漏洞
生產應用程式堆疊 （中等規模團隊，注重安全）：
- 以上所有內容，外加：
- 用於格式化的軟體：Biome 或 Prettier
- 用於安全 SAST 的 Semgrep
- 清除死碼
- SonarCloud 提供高品質的趨勢可見性
企業/單體倉庫堆疊 （團隊規模大，架構有限制）：
- 以上所有內容，外加：
- Dependency-Cruiser 用於模組邊界強制執行
- 用於單體倉庫受影響建置優化的 Nx
- 用於層邊界驗證的Deptrac
- SonarQube（自架）用於本機品質門控
多語言企業堆疊 （TypeScript 與傳統系統並存）：
- 以上所有內容，外加：
- SMART TS XL 用於跨語言影響分析和依賴關係映射
