# 装饰器接入度审计：机制证据 > 端点遍历

> 日期：2026-05-08
> 场景：审计 `@Auditable()` 装饰器在全后端的接入度

## 反模式

要验证"284 个 @Auditable 端点是否真的接入审计"，第一反应是写脚本逐个 HTTP 调一遍 + 查 audit_log 增量。这条路有三个坑：

1. **mutation 接口大多数 4xx**：缺 body / 缺路径参数，验证管道直接拦截，跑出来的全是 FAILED 路径，跟 SUCCESS 链路不等价。
2. **副作用风险**：随机调 POST/PUT/DELETE 会创建脏数据、触发通知/同步、误删资源，dev DB 容易污染。
3. **GET 类装饰器可能为 0**：合规审计普遍只审 mutation，"安全只调 GET"方案直接跑空。

## 正确做法

当装饰器满足以下三个条件时，**机制层单点测试**能传递性证明全量接入：

1. 装饰器只是元数据写入（`SetMetadata`），所有调用点元数据等价
2. 拦截器/Guard 全局注册（`APP_INTERCEPTOR` / `APP_GUARD`），对所有请求一处实现
3. 拦截器用 `Reflector.getAllAndOverride(KEY, [handler, controller])` 读取元数据

满足以上三点 → 任意 1 个端点的端到端集成测试通过，即可推及全部装饰点。剩下的工作分两类：
- **静态层**：扫装饰器声明清单（端点、module、verb、是否敏感/财务）
- **历史证据层**：查 audit_log 表里实际产生过日志的 controller 名分布，识别"声明在位但流量未触达"的灰区

不要把"端点遍历"当成验证手段。

## 副产物：写"接入度"报告时该回答的问题

不是"有没有调过"，而是：
- 装饰器声明覆盖面有多大？（静态扫）
- 机制本身是否有自动化测试守住？（一处即可）
- 真实流量证据分布如何？（audit_log group by module）
- 哪些边界**机制层兜不住**？（business module 命名、entityType 提取、Sensitive/Financial 标记是否齐全、oldValue 落盘）

把这四个层次摆出来，就比"调 280 次接口"的报告信息密度高得多。

## 复用脚本

`testing/scripts/audit-coverage-scan.ts` —— 静态扫描 + audit_log 分布查询，无副作用，重跑零成本。