30d - 架构审查清单与反模式

┌─────────────────────────────────────────────────────────────────────┐
│                    AI 辅助架构审查端到端工作流                         │
├─────────────────────────────────────────────────────────────────────┤
│                                                                     │
│  ① 输入准备          ② AI 自动扫描       ③ 问题分类                 │
│  ┌──────────┐      ┌──────────┐       ┌──────────┐               │
│  │ 代码仓库  │─────→│ 依赖分析  │──────→│ P0 阻断性 │               │
│  │ 设计文档  │      │ 模块边界  │       │ P1 重要   │               │
│  │ ADR 记录  │      │ 反模式检测│       │ P2 建议   │               │
│  │ Steering  │      │ 漂移检测  │       │ P3 优化   │               │
│  └──────────┘      └──────────┘       └──────────┘               │
│                                            │                       │
│  ④ 人工确认          ⑤ 修复跟踪         ⑥ 持续监控                 │
│  ┌──────────┐      ┌──────────┐       ┌──────────┐               │
│  │ 架构师审查│─────→│ 创建任务  │──────→│ CI/CD 集成│               │
│  │ 误报过滤  │      │ 优先排序  │       │ PR 级审查 │               │
│  │ 补充发现  │      │ 迭代修复  │       │ 定期扫描  │               │
│  └──────────┘      └──────────┘       └──────────┘               │
│                                                                     │
└─────────────────────────────────────────────────────────────────────┘

你是一位拥有 15 年经验的软件架构师，擅长架构审查和质量评估。
请对以下系统进行全面的架构审查。

## 系统信息
- 系统名称：[名称]
- 技术栈：[语言/框架/数据库/云平台]
- 团队规模：[人数]
- 预期规模：[用户量/数据量/QPS]

## 架构描述
[粘贴架构文档、C4 图、或目录结构]

## 审查要求
请按以下六大维度进行审查，每个维度给出 1-5 分评分：

### 1. 功能完整性（所有功能是否有组件承载？）
### 2. 非功能需求（性能/可用性/扩展性保障？）
### 3. 可维护性（模块边界/耦合度/扩展性？）
### 4. 运维就绪（监控/部署/恢复方案？）
### 5. 成本效益（是否过度设计？成本可控？）
### 6. 安全性（认证/授权/加密/合规？）

## 输出格式
1. **评分卡**：六维度雷达图数据（每个维度 1-5 分）
2. **发现清单**：按优先级（P0/P1/P2）列出所有发现
3. **Top 5 改进建议**：最重要的 5 个改进建议
4. **反模式检测**：识别到的架构反模式
5. **架构漂移风险**：当前架构与设计意图的偏差

请评估以下架构方案是否存在过度工程：

## 项目约束
- 团队规模：[人数]
- 预期 DAU：[数量]
- 上线时间：[月数]

## 架构方案
[粘贴架构描述]

请检查：
1. 组件数量是否与团队规模匹配？
2. 是否有当前不需要的中间件或服务？
3. 哪些组件可以合并或移除而不影响 MVP 功能？
4. 如果简化为最简架构，会失去什么？这些是否是当前必需的？

请评估以下架构方案的运维就绪度：

## 架构方案
[粘贴架构描述]

请检查以下 Day 2 运维能力：
1. **可观测性**：是否有指标收集、日志聚合、链路追踪？
2. **告警**：是否定义了关键告警规则和升级路径？
3. **部署**：是否支持零停机部署和快速回滚？
4. **恢复**：RTO/RPO 是否明确？备份是否经过恢复测试？
5. **安全更新**：依赖漏洞修复流程是否明确？
6. **容量规划**：是否有自动扩缩容策略？
7. **成本监控**：是否有基础设施成本告警？

对每项给出"就绪/部分就绪/未就绪"评估，并提供改进建议。

请审查以下技术选型是否存在技术偏见：

## 项目需求
[描述项目核心需求和约束]

## 当前技术选型
[列出选择的技术栈]

请检查：
1. 每个技术选择是否有明确的需求驱动？
2. 是否考虑过更简单/更成熟的替代方案？
3. 团队对选择的技术是否有足够经验？
4. 是否存在"用大炮打蚊子"的情况？
5. 请推荐至少 1 个可能更适合但不太热门的替代方案。

请评估以下架构方案是否存在过早优化：

## 当前规模
- DAU：[数量]
- 峰值 QPS：[数量]
- 数据量：[大小]

## 架构方案
[粘贴架构描述]

请检查：
1. 哪些组件/模式在当前规模下是不必要的？
2. 缓存层是否有实际的性能需求支撑？
3. 消息队列是否有实际的异步处理需求？
4. 读写分离/分库分表是否有数据量支撑？
5. 建议移除哪些优化，改为在什么条件下再引入？

请对以下架构方案进行故障模式分析（FMEA）：

## 架构方案
[粘贴架构描述]

对每个关键组件，请分析：

| 组件 | 故障模式 | 影响范围 | 检测方式 | 恢复策略 | 降级方案 |
|------|---------|---------|---------|---------|---------|

特别关注：
1. 数据库不可用时，系统如何响应？
2. 第三方 API 超时时，用户体验如何？
3. 消息队列积压时，如何处理？
4. 缓存失效时，是否会导致数据库雪崩？
5. 网络分区时，数据一致性如何保证？
6. 单个服务 OOM 时，是否会级联影响其他服务？

请评估以下架构迁移方案的可行性：

## 当前架构
[描述现有架构]

## 目标架构
[描述目标架构]

## 迁移计划
[粘贴迁移计划]

请检查：
1. 迁移是否分阶段？每个阶段是否可独立回滚？
2. 数据迁移方案是否完整？是否有一致性验证？
3. 迁移期间的双写/双读策略是否明确？
4. 流量切换策略是否支持渐进式（灰度）？
5. 迁移时间估算是否合理？（通常需要乘以 3-5 倍安全系数）
6. 对现有用户的影响是否评估？是否有沟通计划？
7. 最坏情况下的回滚方案是什么？回滚需要多长时间？

你是一位架构健康度评估专家。请对以下代码仓库进行架构健康度评估。

## 仓库信息
- 语言：[TypeScript/Python/Go/Java]
- 框架：[框架名称]
- 目录结构：
[粘贴 tree 命令输出]

## 评估维度（每个维度 1-5 分）

### 1. 模块化程度
- 模块边界是否清晰？
- 模块间耦合度是否可接受？
- 是否存在"上帝模块"？

### 2. 依赖健康度
- 是否存在循环依赖？
- 依赖方向是否正确（高层不依赖低层实现）？
- 外部依赖是否通过适配器隔离？

### 3. 代码组织
- 目录结构是否反映架构意图？
- 命名是否一致且有意义？
- 关注点分离是否到位？

### 4. 可测试性
- 核心逻辑是否可以独立测试？
- 依赖注入是否广泛使用？
- 测试覆盖率是否充足？

### 5. 可扩展性
- 新功能添加是否需要修改核心代码？
- 是否有明确的扩展点？
- 配置是否外部化？

### 6. 运维就绪度
- 日志是否结构化？
- 健康检查是否实现？
- 错误处理是否一致？

## 输出格式
1. **健康度评分卡**（六维度雷达图数据）
2. **Top 5 架构风险**（按严重度排序）
3. **改进路线图**（短期/中期/长期）
4. **Steering 规则建议**（防止进一步退化）

# .github/workflows/architecture-health.yml
name: Architecture Health Check
 
on:
  push:
    branches: [main]
  schedule:
    - cron: '0 9 * * 1'  # 每周一早上 9 点
 
jobs:
  health-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
 
      - name: 检查循环依赖
        run: |
          npx dependency-cruiser --config .dependency-cruiser.cjs src/ \
            --output-type err
 
      - name: 检查模块边界
        run: |
          npx dependency-cruiser --config .dependency-cruiser.cjs src/ \
            --output-type archi \
            --output-to reports/dependency-graph.svg
 
      - name: 计算复杂度指标
        run: |
          npx eslint src/ --format json --output-file reports/complexity.json \
            --rule '{"complexity": ["warn", 10]}'
 
      - name: 生成架构健康度报告
        run: |
          echo "## 架构健康度报告 $(date)" > reports/health-report.md
          echo "" >> reports/health-report.md
          echo "### 循环依赖" >> reports/health-report.md
          npx dependency-cruiser --config .dependency-cruiser.cjs src/ \
            --output-type text >> reports/health-report.md || true
          echo "" >> reports/health-report.md
          echo "### 复杂度警告" >> reports/health-report.md
          cat reports/complexity.json | jq '.[] | .messages[] | .message' \
            >> reports/health-report.md || true
 
      - name: 上传报告
        uses: actions/upload-artifact@v4
        with:
          name: architecture-health-report
          path: reports/

┌─────────────────────────────────────────────────────────┐
│              AI 驱动的架构漂移检测工作流                     │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  ① 架构基线定义       ② 实际架构提取                     │
│  ┌──────────────┐   ┌──────────────┐                   │
│  │ 设计文档      │   │ 代码依赖分析  │                   │
│  │ C4 模型      │   │ import 图谱   │                   │
│  │ ADR 记录     │   │ API 调用链    │                   │
│  │ Steering 规则│   │ 数据访问模式  │                   │
│  └──────┬───────┘   └──────┬───────┘                   │
│         │                   │                           │
│         └───────┬───────────┘                           │
│                 ▼                                       │
│  ③ AI 对比分析                                          │
│  ┌──────────────────────────────────┐                  │
│  │ · 设计依赖 vs 实际依赖            │                  │
│  │ · 模块边界是否被突破              │                  │
│  │ · API 契约是否变更                │                  │
│  │ · 新增组件是否符合架构模式         │                  │
│  └──────────────┬───────────────────┘                  │
│                 ▼                                       │
│  ④ 漂移报告                                            │
│  ┌──────────────────────────────────┐                  │
│  │ · 漂移清单（按严重度排序）         │                  │
│  │ · 每个漂移的影响分析              │                  │
│  │ · 修复建议和优先级                │                  │
│  │ · Steering 规则更新建议           │                  │
│  └──────────────────────────────────┘                  │
│                                                         │
└─────────────────────────────────────────────────────────┘

请对比以下架构设计文档和实际代码结构，检测架构漂移：

## 设计文档中的架构意图
[粘贴架构设计文档或 C4 图]

## 实际代码结构
[粘贴 tree 命令输出或依赖分析结果]

## Steering 规则（架构约束）
[粘贴 Steering 规则]

请检测以下类型的漂移：

1. **依赖漂移**：是否存在设计中不允许的模块间依赖？
2. **边界漂移**：是否有模块的内部实现被外部直接访问？
3. **职责漂移**：是否有组件承担了设计中未分配的职责？
4. **通信漂移**：组件间通信方式是否偏离设计？
5. **命名漂移**：代码中的命名是否与架构文档一致？

## 输出格式
| 漂移类型 | 位置 | 设计意图 | 实际情况 | 严重度 | 修复建议 |
|---------|------|---------|---------|--------|---------|

# sonar-architecture.yaml
# 定义意图架构：分层架构 + 模块边界
 
perspectives:
  - name: "分层架构"
    groups:
      - name: "表现层"
        includes:
          - "src/controllers/**"
          - "src/routes/**"
          - "src/middleware/**"
      - name: "业务层"
        includes:
          - "src/services/**"
          - "src/domain/**"
      - name: "数据层"
        includes:
          - "src/repositories/**"
          - "src/models/**"
      - name: "基础设施层"
        includes:
          - "src/infrastructure/**"
          - "src/config/**"
 
constraints:
  # 表现层只能依赖业务层
  - from: "表现层"
    allow:
      - "业务层"
    deny:
      - "数据层"        # 禁止表现层直接访问数据层
      - "基础设施层"     # 禁止表现层直接访问基础设施层
 
  # 业务层可以依赖数据层，但不能依赖表现层
  - from: "业务层"
    allow:
      - "数据层"
    deny:
      - "表现层"        # 禁止业务层依赖表现层（反向依赖）
 
  # 数据层不能依赖业务层和表现层
  - from: "数据层"
    deny:
      - "业务层"
      - "表现层"

// .dependency-cruiser.cjs
/** @type {import('dependency-cruiser').IConfiguration} */
module.exports = {
  forbidden: [
    // 禁止循环依赖
    {
      name: 'no-circular',
      severity: 'error',
      comment: '禁止循环依赖，这会导致模块边界模糊',
      from: {},
      to: { circular: true }
    },
    // 禁止表现层直接访问数据层
    {
      name: 'no-controller-to-repository',
      severity: 'error',
      comment: '控制器不能直接访问 Repository，必须通过 Service 层',
      from: { path: '^src/controllers/' },
      to: { path: '^src/repositories/' }
    },
    // 禁止业务层依赖表现层
    {
      name: 'no-service-to-controller',
      severity: 'error',
      comment: '服务层不能依赖控制器层（反向依赖）',
      from: { path: '^src/services/' },
      to: { path: '^src/controllers/' }
    },
    // 禁止跨模块直接访问内部实现
    {
      name: 'no-cross-module-internals',
      severity: 'warn',
      comment: '模块间只能通过公共接口（index.ts）通信',
      from: { path: '^src/modules/([^/]+)/' },
      to: {
        path: '^src/modules/([^/]+)/',
        pathNot: [
          '^src/modules/$1/',           // 同模块内部允许
          '^src/modules/[^/]+/index\\.ts$'  // 其他模块的公共接口允许
        ]
      }
    }
  ],
  options: {
    doNotFollow: {
      path: 'node_modules'
    },
    tsPreCompilationDeps: true,
    tsConfig: { fileName: 'tsconfig.json' }
  }
};

请对以下 PR 进行架构级审查（不是代码风格审查）：

## PR 变更摘要
[粘贴 PR 描述或 git diff --stat 输出]

## 架构约束（Steering 规则）
[粘贴项目的架构 Steering 规则]

请检查以下架构关注点：

### 1. 模块边界
- 变更是否跨越了模块边界？
- 是否引入了新的跨模块依赖？
- 新依赖是否符合架构约束？

### 2. 分层合规
- 是否存在跨层直接调用（如控制器直接访问数据库）？
- 依赖方向是否正确？

### 3. API 契约
- 是否修改了公共 API？是否向后兼容？
- 新 API 是否遵循项目的 API 设计规范？

### 4. 数据模型
- 是否修改了数据库 Schema？是否有迁移文件？
- 数据模型变更是否影响其他模块？

### 5. 安全性
- 是否引入了新的外部依赖？是否有已知漏洞？
- 是否有硬编码的密钥或配置？

## 输出格式
- 🔴 阻断性问题（必须修复才能合并）
- 🟡 建议改进（建议修复但不阻断）
- 🟢 信息提示（供参考）

请进行本季度的架构健康度审查。

## 项目信息
- 项目名称：[名称]
- 上次审查日期：[日期]
- 本季度主要变更：[列出重大功能/架构变更]

## 审查范围
[粘贴当前代码库结构或架构图]

## 上次审查的遗留问题
[列出上次审查发现但未修复的问题]

## 请执行以下审查：

### 1. 架构漂移评估
- 当前代码结构是否仍然符合设计文档？
- 是否有新的模块边界违规？
- ADR 中的决策是否仍然有效？

### 2. 技术债务盘点
- 新增了哪些技术债务？
- 上次识别的技术债务是否有改善？
- 技术债务的"利息"是否在增长？

### 3. 架构演进评估
- 当前架构是否仍然满足业务需求？
- 是否需要进行架构演进？触发条件是什么？
- 下一步架构改进的优先级建议

### 4. 安全态势评估
- 是否有新的安全风险？
- 依赖漏洞是否及时修复？
- 安全架构是否需要更新？

## 输出格式
1. **健康度评分卡**（与上次对比）
2. **新发现问题清单**（按优先级排序）
3. **遗留问题进展**
4. **下季度改进建议**（Top 3）
5. **Steering 规则更新建议**

请对以下系统进行架构反模式检测。

## 系统信息
- 技术栈：[语言/框架/数据库]
- 团队规模：[人数]
- 系统年龄：[月/年]
- 当前规模：[用户量/数据量]

## 代码结构
[粘贴目录结构或依赖分析结果]

## 架构描述
[粘贴架构文档或 C4 图]

请检测以下 12 个架构反模式：

1. **过度工程**：组件数量是否与需求规模匹配？
2. **忽视运维成本**：可观测性和运维自动化是否就绪？
3. **技术偏见**：技术选型是否有需求驱动？
4. **过早优化**：是否有当前规模不需要的优化机制？
5. **缺少故障模式分析**：故障场景是否有设计？
6. **迁移复杂度低估**：架构演进计划是否可行？
7. **大泥球**：模块边界是否清晰？依赖是否有序？
8. **分布式单体**：微服务是否真正独立？
9. **供应商锁定**：核心逻辑是否与云平台解耦？
10. **缺少 API 版本管理**：API 是否有版本策略？
11. **日志黑洞**：日志和监控是否有效？
12. **配置硬编码**：配置是否外部化？

## 输出格式
对每个反模式：
- **检测结果**：存在 / 不存在 / 有风险
- **证据**：具体的代码位置或架构特征
- **严重度**：🔴 高 / 🟡 中 / 🟢 低
- **修复建议**：具体的改进措施
- **修复优先级**：P0 / P1 / P2

请对以下新项目的架构方案进行启动前审查。

## 项目背景
- 项目类型：[SaaS/电商/内部工具/API 平台]
- 团队规模：[人数]
- 上线时间：[截止日期]
- 预期规模：[用户量/数据量]
- 预算：[月度基础设施预算]

## 架构方案
[粘贴架构设计文档]

## 审查重点

### 1. 方案合理性
- 架构复杂度是否与项目规模匹配？
- 技术选型是否与团队能力匹配？
- 是否遵循了"最简可行架构"原则？

### 2. 风险识别
- Top 5 架构风险是什么？
- 每个风险的缓解措施是否充分？
- 是否有"致命假设"需要尽早验证？

### 3. 演进可行性
- 从 MVP 到成熟期的演进路径是否清晰？
- 演进过程中的关键决策点是什么？
- 是否为未来的架构变更预留了接缝？

### 4. 遗漏检查
- 是否遗漏了关键的非功能需求？
- 安全设计是否完整？
- 运维就绪度是否考虑？

## 输出格式
1. **总体评价**：通过 / 有条件通过 / 需要重大修改
2. **必须修改项**（阻断性问题）
3. **建议修改项**（改进建议）
4. **风险登记表**
5. **启动前检查清单**（确认所有前置条件满足）

# 架构约束 Steering 规则
 
## 分层架构约束
- 控制器层（controllers/）只能调用服务层（services/），禁止直接访问数据层
- 服务层（services/）可以调用数据层（repositories/），禁止依赖控制器层
- 数据层（repositories/）不能依赖服务层和控制器层
- 工具函数（utils/）不能依赖任何业务层
 
## 模块边界约束
- 模块间通过公共接口（index.ts）通信，禁止直接导入其他模块的内部文件
- 每个模块拥有独立的数据模型，禁止跨模块直接查询数据库表
- 新增跨模块依赖必须在 PR 描述中说明理由
 
## 数据访问约束
- 所有数据库操作必须通过 ORM（Prisma/Drizzle），禁止原始 SQL（除非有性能优化的 ADR 支持）
- 数据库迁移必须可回滚，禁止破坏性变更（如删除列）不提供回滚脚本
- 缓存操作必须通过统一的缓存服务，禁止直接调用 Redis 客户端
 
## 配置管理约束
- 所有环境相关配置通过环境变量注入，禁止硬编码
- 密钥和凭证必须通过密钥管理服务，禁止出现在代码仓库中
- 功能开关通过配置服务管理，禁止硬编码 if/else 分支
 
## API 设计约束
- 所有 API 必须包含版本号（/api/v1/...）
- API 响应格式必须统一（{ data, error, meta }）
- 破坏性 API 变更必须创建新版本，旧版本保留至少 3 个月
 
## 错误处理约束
- 所有异步操作必须有错误处理（try/catch 或 .catch()）
- 错误响应必须包含错误码、错误消息和请求 ID
- 禁止吞掉异常（catch 块中不能为空）
 
## 日志和监控约束
- 所有 API 请求必须记录结构化日志（JSON 格式）
- 日志必须包含：请求 ID、用户 ID、操作类型、耗时、状态码
- 关键业务操作必须记录审计日志
- 新增服务必须实现 /health 健康检查端点

# 微服务架构 Steering 规则
 
## 服务边界
- 每个微服务对应一个限界上下文，不按技术层划分
- 服务数量不超过团队人数的 2 倍
- 如果两个服务总是一起部署，考虑合并为一个服务
 
## 通信约束
- 同步调用链不超过 3 层
- 跨服务数据查询优先使用 CQRS 读模型，而非级联 API 调用
- 所有异步通信必须设计幂等性和重试策略
- 服务间通信必须有超时配置（默认 5 秒）
- 必须配置熔断器（Circuit Breaker），防止级联故障
 
## 数据管理
- 每个服务拥有自己的数据库 Schema 或数据库实例
- 禁止跨服务直接访问数据库
- 数据同步使用事件驱动，而非定时批量同步
- 分布式事务使用 Saga 模式，禁止两阶段提交（2PC）
 
## 部署约束
- 每个服务必须可以独立部署和回滚
- 服务间的 API 变更必须向后兼容
- 新版本部署必须支持金丝雀发布
 
## 可观测性
- 每个服务必须暴露 Prometheus 指标端点
- 所有跨服务调用必须传播链路追踪上下文（Trace ID）
- 每个服务必须有独立的日志流

# 模块化单体架构 Steering 规则
 
## 模块定义
- 每个业务领域对应一个模块目录（src/modules/{module-name}/）
- 模块必须有公共接口文件（index.ts），只导出公共 API
- 模块内部文件不能被其他模块直接导入
 
## 模块间通信
- 模块间通过公共接口通信，禁止直接访问内部实现
- 模块间数据传递使用 DTO（Data Transfer Object），禁止传递内部实体
- 跨模块事件使用内部事件总线，为未来拆分预留接缝
 
## 数据隔离
- 每个模块拥有独立的数据库 Schema（schema-per-module）
- 禁止跨模块 JOIN 查询
- 共享数据通过事件同步或 API 调用获取
 
## 未来拆分预留
- 模块间不共享内存状态
- 模块间通信可以替换为网络调用（接口设计兼容）
- 每个模块的依赖可以独立管理

请帮我准备架构审查会议材料：

## 审查范围
- 时间范围：[上次审查日期] 至今
- 主要变更：[列出重大变更]

请生成：
1. **架构变更摘要**（1 页，列出所有架构相关变更）
2. **健康度对比**（与上次审查的指标对比）
3. **新发现问题**（AI 自动检测的架构问题）
4. **讨论议题**（需要团队讨论的架构决策）
5. **决策模板**（会议中需要做的决策的 ADR 模板）

# 架构审查会议议程
 
## 基本信息
- 日期：[日期]
- 参与者：[名单]
- 时长：60 分钟
 
## 议程
 
### 1. 回顾（10 分钟）
- 上次审查的遗留问题进展
- 本周期的架构变更摘要
 
### 2. 健康度报告（10 分钟）
- AI 生成的架构健康度评分
- 关键指标趋势（耦合度、复杂度、技术债务）
 
### 3. 问题讨论（25 分钟）
- AI 检测到的架构问题
- 团队提出的架构关注点
- 需要决策的架构问题
 
### 4. 决策和行动项（10 分钟）
- 记录架构决策（ADR）
- 分配修复任务和优先级
- 更新 Steering 规则（如需要）
 
### 5. 下次审查计划（5 分钟）
- 确认下次审查日期
- 确认重点关注领域

请对当前代码仓库进行全面的架构健康度扫描。

重点关注：
1. 模块边界是否清晰？是否有循环依赖？
2. 是否存在"上帝模块"（职责过多的模块）？
3. 数据访问模式是否规范？是否有跨层直接调用？
4. 错误处理是否一致？
5. 日志和监控是否完整？
6. 是否存在硬编码配置？
7. API 设计是否一致？

## 架构健康度评分

| 维度 | 评分 | 说明 |
|------|------|------|
| 模块化程度 | 3/5 | 模块边界基本清晰，但存在 3 处循环依赖 |
| 依赖健康度 | 2/5 | 发现 5 处跨层直接调用，2 个"上帝模块" |
| 代码组织 | 4/5 | 目录结构合理，命名一致 |
| 可测试性 | 3/5 | 核心逻辑可测试，但部分服务缺少依赖注入 |
| 运维就绪度 | 2/5 | 缺少结构化日志，无链路追踪，健康检查不完整 |
| 安全性 | 3/5 | 认证方案合理，但发现 2 处硬编码配置 |

## 发现的反模式
1. 🔴 **大泥球趋势**：order 模块直接导入 user 模块的内部实现
2. 🔴 **日志黑洞**：日志格式不统一，无请求 ID 追踪
3. 🟡 **过早优化**：引入了 Redis 缓存层，但缓存命中率未监控
4. 🟡 **配置硬编码**：2 处第三方 API 密钥硬编码在代码中
5. 🟡 **缺少 API 版本管理**：所有 API 无版本号

# 电商平台架构 Steering 规则（基于 2025-XX 架构审查）
 
## 模块边界（修复 P1 模块边界侵蚀）
- order 模块不能直接导入 user 模块的内部文件
- 模块间通信必须通过 modules/{name}/index.ts 公共接口
- 新增跨模块依赖必须在 PR 中说明理由
 
## 配置管理（修复 P0 硬编码密钥）
- 禁止在代码中硬编码 API 密钥、数据库连接串等敏感信息
- 所有配置通过 src/config/ 统一管理，从环境变量读取
- 新增第三方服务集成必须使用 Secrets Manager
 
## 日志标准（修复 P0 日志黑洞）
- 所有日志使用 Pino JSON 格式
- 每条日志必须包含：requestId, userId, action, duration
- 新增 API 端点必须有请求/响应日志
 
## API 规范（修复 P1 API 版本管理）
- 所有 API 路径必须包含版本号：/api/v1/...
- API 响应格式：{ data, error, pagination }
- 破坏性变更必须创建新版本