# P5.1→NS3 缺失项 #4：App4-App7 的缓存策略

## 简要结论
- 状态：⚠️ 部分解决
- 风险等级：🟠 中
- cache_type 枚举和保留策略（500 条上限 + 清理机制）已实现，但缺少 expires_at 过期策略和主动失效条件的定义与实现。

## 详细审查

### 审查范围
- `apps/backend/app/ai/cache_service.py` — AI 缓存读写服务
- `apps/backend/app/ai/schemas.py` — CacheTypeEnum 枚举定义
- `docs/database/ddl/zqyy_app__biz.sql` — ai_cache 表 DDL
- `docs/prd/specs/P5-miniapp-ai-integration.md` — P5 spec 缓存策略定义

### 发现

#### ✅ 已实现部分

1. **cache_type 枚举**：`schemas.py` 中 `CacheTypeEnum` 定义了 7 个枚举值：
   ```python
   APP2_FINANCE = "app2_finance"
   APP3_CLUE = "app3_clue"
   APP4_ANALYSIS = "app4_analysis"
   APP5_TACTICS = "app5_tactics"
   APP6_NOTE_ANALYSIS = "app6_note_analysis"
   APP7_CUSTOMER_ANALYSIS = "app7_customer_analysis"
   APP8_CLUE_CONSOLIDATED = "app8_clue_consolidated"
   ```
   与 P5 spec 定义完全一致。

2. **保留策略**：`cache_service.py` 的 `_cleanup_excess()` 实现了 P5 spec 定义的"每个 (cache_type, site_id, target_id) 组合保留最近 500 条记录"：
   ```python
   def _cleanup_excess(self, ..., max_count: int = 500) -> int:
   ```
   清理时机：每次 `write_cache()` 写入新记录后异步清理。

3. **target_id 约定**：各应用的 target_id 含义在 P5 spec 中有明确定义（App2=时间维度编码、App3/6/7/8=member_id、App4/5=assistant_id_member_id）。

4. **数据库表结构**：`ai_cache` 表包含 `expires_at timestamp with time zone` 字段，DDL 层面支持过期时间。

#### ❌ 未实现部分

1. **expires_at 过期策略**：
   - DDL 中 `expires_at` 字段存在但代码中从未设置有效值
   - `write_cache()` 接受 `expires_at` 参数，但所有调用方（App2-App8 的 `run()` 函数）均未传入 `expires_at`
   - 没有定时任务或查询逻辑检查 `expires_at` 并清理过期记录
   - `get_latest()` 查询时不过滤已过期记录

2. **主动失效条件**：
   - P5 spec 未定义具体的失效条件（如"数据源更新后旧缓存失效"）
   - NS3 spec 提到"ai_cache 表但未定义策略"——确实如此
   - 当前实现是"只增不删"（除 500 条上限清理外），没有基于业务事件的缓存失效机制

3. **缓存读取时的新鲜度检查**：
   - `get_latest()` 仅按 `created_at DESC` 取最新一条，不检查缓存是否仍然有效
   - 前端读取缓存时无法判断数据是否过时

### 证据

`cache_service.py` 中 `write_cache()` 的 `expires_at` 参数：
```python
def write_cache(
    self,
    cache_type: str,
    site_id: int,
    target_id: str,
    result_json: dict,
    triggered_by: str | None = None,
    score: int | None = None,
    expires_at: datetime | None = None,  # 接受但从未被调用方传入
) -> int:
```

App2 调用 `write_cache` 时未传入 `expires_at`：
```python
cache_svc.write_cache(
    cache_type=CacheTypeEnum.APP2_FINANCE.value,
    site_id=site_id,
    target_id=time_dimension,
    result_json=result,
    triggered_by=f"user:{user_id}",
    # 无 expires_at
)
```

DDL 中 `expires_at` 字段定义：
```sql
expires_at timestamp with time zone  -- 存在但未被使用
```

### 建议

1. **定义各应用的缓存过期策略**：
   | 应用 | 建议 expires_at | 理由 |
   |------|----------------|------|
   | App2 | 当日 08:00（营业日切点） | 财务数据每日更新，次日数据变化后旧缓存无意义 |
   | App3 | 7 天 | 消费数据线索在下次消费前有效 |
   | App4/5 | 3 天 | 关系分析和话术时效性较强 |
   | App6 | 无过期 | 备注分析结果不会因时间失效 |
   | App7 | 7 天 | 客户分析随新数据更新 |
   | App8 | 无过期 | 整合线索由上游触发更新 |

2. **实现过期检查**：在 `get_latest()` 中增加 `WHERE expires_at IS NULL OR expires_at > NOW()` 过滤。

3. **考虑增加缓存失效事件**：当 App3/App6 产出新内容后，可标记旧的 App7 缓存为失效，确保前端读到最新分析。