项目分析

wescode 提供全面的项目分析能力，帮助你快速理解代码库结构、依赖关系、架构质量和技术债务。

功能概览

能力说明
代码统计文件数量、代码行数、语言分布
依赖关系包依赖、模块依赖、循环依赖检测
调用图可视化交互式 D3 调用图，支持多级展开
架构检查分层架构合规、边界违规检测
技术债评估复杂度分析、重复代码、过时依赖

代码统计

项目概览面板

点击左侧活动栏的「项目概览」图标，进入三区域布局面板：

统计维度

指标说明
总代码行数不含空行和注释
文件总数按语言/目录分组
语言分布Go / TypeScript / Python 等占比
包/模块数Go packages、npm packages 等
测试覆盖率从测试运行结果中提取

使用方式

用户：分析这个项目的代码规模

AI：项目统计：
  语言分布：Go 78% | TypeScript 15% | SQL 4% | Other 3%
  代码行数：约 45,000 行（不含测试）
  测试代码：约 12,000 行
  Go 包数量：67 个
  主要目录：
    cmd/         — 入口（3 个子命令）
    internal/    — 业务逻辑（42 个包）
    pkg/         — 公共库（8 个包）
    web/         — 前端（React）

依赖关系

包依赖分析

wescode 通过 CKG 构建完整的包依赖图：

用户：分析 internal/service 的依赖关系

AI：internal/service 依赖分析：
  直接依赖（8个）：
    ← internal/repository  （数据访问）
    ← internal/model        （领域模型）
    ← internal/config       （配置）
    ← pkg/logger            （日志）
    ...
  被依赖（3个）：
    → internal/handler      （HTTP handler）
    → internal/middleware    （中间件）
    → cmd/server            （主入口）
  ⚠ 无循环依赖

循环依赖检测

CKG 会自动检测并报告循环依赖：

⚠ 循环依赖检测到：
  internal/auth → internal/user → internal/auth
  建议：提取公共接口到 internal/types 打破循环

外部依赖审计

用户：检查第三方依赖的安全性

AI：依赖审计报告：
  总依赖数：45 个（直接 12 + 间接 33）
  ⚠ 需要关注：
    - golang.org/x/crypto v0.14.0 — 存在已知漏洞 CVE-2024-xxxx
      建议升级到 v0.21.0+
    - github.com/dgrijalva/jwt-go — 已弃用
      建议迁移到 github.com/golang-jwt/jwt/v5
  ✓ 其余依赖无已知安全问题

调用图可视化

交互式调用图

项目概览面板中的调用图基于 CKG 构建，支持：

调用图操作

操作说明
单击节点展开/折叠子调用
双击节点跳转到源代码
右键节点查看详细信息（入参、返回值、调用次数）
鼠标悬停显示函数签名和文档注释
滚轮缩放调整视图层级
拖拽移动平移调用图

在 Chat 中使用

用户：画出 HandleCreateOrder 的调用链

AI：HandleCreateOrder 调用链：
  HandleCreateOrder (handler/order.go)
  ├── ValidateOrder (service/order.go)
  │   ├── CheckInventory (service/inventory.go)
  │   └── ValidatePayment (service/payment.go)
  ├── CreateOrder (service/order.go)
  │   ├── SaveOrder (repository/order.go)
  │   └── PublishEvent (event/publisher.go)
  └── SendNotification (service/notification.go)

架构检查

分层架构合规

wescode 的 CSE（约束满足引擎）可以检查代码是否遵循预定的架构规则：

用户：检查分层架构是否有违规

AI：架构合规检查结果：
  ✓ handler → service → repository 层次正确
  ✗ 违规 1：handler/user.go 直接调用 repository/user.go
    → handler 层不应绕过 service 层直接访问 repository
  ✗ 违规 2：service/order.go 导入 handler/dto 包
    → service 层不应依赖 handler 层的数据结构
  建议：
    1. handler/user.go 的数据库操作移到 service/user.go
    2. service/order.go 使用自己的领域模型替代 handler/dto

边界违规检测

CSE 通过 13 个 Checker 检测各类架构约束：

自定义规则

可以在项目根目录创建 .wescode/constraints.yaml 定义自定义约束：

rules:
  - name: "handler-no-direct-db"
    description: "Handler 层禁止直接访问数据库"
    deny:
      from: "internal/handler/**"
      to: "internal/repository/**"
  - name: "no-global-state"
    description: "禁止使用全局可变状态"
    deny:
      pattern: "var.*=.*sync\\.Map|var.*=.*make\\(map"

技术债评估

复杂度分析

用户：找出项目中最复杂的函数

AI：圈复杂度 Top 5：
  1. processPayment (service/payment.go) — 复杂度 32
     → 建议拆分为 validatePayment + executePayment + handleResult
  2. parseConfig (config/loader.go) — 复杂度 28
     → 建议使用策略模式替代 switch-case
  3. renderTemplate (template/engine.go) — 复杂度 24
     → 建议将模板类型处理拆分为独立函数
  4. handleWebhook (handler/webhook.go) — 复杂度 21
  5. migrateDatabase (db/migration.go) — 复杂度 19

重复代码检测

用户：检查重复代码

AI：重复代码检测结果：
  发现 6 处重复代码块：
  1. handler/user.go:45-62 ≈ handler/order.go:30-47
     → 错误处理逻辑重复，建议提取为 handleError 中间件
  2. service/email.go:100-130 ≈ service/sms.go:80-110
     → 通知发送逻辑重复，建议抽象为 Notifier 接口
  ...

过时依赖检查

用户：哪些依赖需要更新？

AI：依赖更新建议：
  ⬆ 需要更新（5个）：
    github.com/gin-gonic/gin     1.9.1 → 1.10.0（安全修复）
    google.golang.org/grpc       1.58.0 → 1.64.0（性能优化）
    ...
  ⚠ 已弃用（1个）：
    github.com/pkg/errors        → 建议迁移到标准库 errors
  ✓ 已是最新（39个）

项目健康度报告

生成综合报告

用户：生成项目健康度报告

AI：📊 项目健康度报告
  ━━━━━━━━━━━━━━━━━━━━━━━━━━
  总体评分：B+（78/100）

  ✓ 代码质量：85/100
    - 测试覆盖率 72%
    - 平均圈复杂度 8.2
    - lint 通过率 96%

  ⚠ 架构健康：70/100
    - 2 处分层违规
    - 1 处循环依赖
    - 3 处跨模块耦合

  ⚠ 依赖管理：75/100
    - 1 个已弃用依赖
    - 2 个需安全更新
    - 间接依赖过多（33个）

  ✓ 文档完整性：82/100
    - API 文档覆盖率 85%
    - README 完整
    - 缺少架构决策记录

注意事项