金融业务系统的前端权限与操作可追溯：设计要点与落地方式

wuwenzen@outlook.com (wuwj) — Tue, 25 Mar 2025 00:00:00 +0000

背景

在金融业务系统中，“能不能做”与“做了什么”通常同等重要：

权限需要细粒度（页面、模块、动作）
高风险操作需要二次确认与留痕
线上问题需要可追溯（谁、在何时、做了什么）

前端并非审计的最终来源，但前端是“入口层”，对降低误操作与提升可追溯性非常关键。

1. 权限模型：动作权限作为最小单元

推荐以“动作权限”作为最小单元（而不是只做菜单/页面）：

{
  "resource": "order:review",
  "actions": ["view", "approve", "reject", "export"]
}

落地到前端的三层控制：

路由守卫：控制页面是否可进入
组件/指令：控制按钮、入口是否可见/可用
请求层兜底：对敏感接口做二次校验（避免绕过 UI）

2. 操作风险分级：不同级别用不同交互

建议对操作做风险分级（示例）：

低风险：查询、查看详情
中风险：提交、发起流程、修改关键字段
高风险：审批通过、批量处理、导出敏感数据

不同级别对应不同交互策略：

中风险：二次确认 + 明确影响范围
高风险：强确认（输入关键字/再次校验）+ 明确告知留痕

3. 操作留痕：前端如何参与“可追溯”

前端侧建议做三件事：

3.1 为关键动作生成 traceId

每次关键操作生成 traceId
随请求携带到后端
前后端日志用同一 traceId 串联

3.2 标准化审计字段（脱敏）

建议上报结构化字段：

action（动作编码）
resource（资源编码）
targetId（业务对象 id）
result（success/fail）
reason（失败原因码）

避免：把敏感字段明文写入日志/埋点。

3.3 失败也要可追溯

很多事故来自失败重试与重复提交：

失败原因要可读（错误码映射）
可操作指引要明确（下一步做什么）
必要时提供“一键复制 traceId”入口，方便支持排查

4. 误操作防护：前端的“最后一道门”

常见防护手段：

按钮防抖 + 请求幂等 key（避免重复提交）
表单关键字段修改提示（脏数据提示）
高风险操作的预检查（权限、状态、前置条件）
批量操作的预览（影响范围、条数、筛选条件回显）

5. 可维护性：权限与路由不要绑死在页面

建议将权限控制抽象成“能力层”：

调用大模型 API 的几个最佳实践：重试、降级与审计

wuwenzen@outlook.com (wuwj) — Mon, 05 Jun 2023 00:00:00 +0000

刚开始用大模型 API 时，大家一般关心的是：

这个模型效果好不好？回答聪不聪明？

但当你真的把它作为「线上能力」接入产品时，会发现很多工程问题：

API 偶尔超时 / 报错怎么办？
费用怎么控？
返回内容里如果有敏感信息怎么办？
出了问题，怎么排查某次请求？

这篇文章就是从这些「落地问题」出发，整理几条接入大模型 API 的最佳实践。

1. 超时与重试：别把前端一直挂着

1.1 超时要有明确上限

大模型生成本身需要时间，如果不设超时，前端可能会一直转圈。
我们一般做法：

在 BFF / 中间层对每个调用设定超时时间（例如 10–15 秒）；
超时后直接返回「超时错误」，由前端给出友好提示；
前端也设置请求超时，避免被挂死。

1.2 重试策略

常见错误类型：

临时网络抖动；
API 限流（429）；
服务端偶发异常。

对幂等请求（比如生成建议文案），我们采用：

指数退避重试：例如最多重试 2 次，间隔 500ms / 1000ms；
遇到某些错误码（如 4xx 中的参数错误）不重试。

伪代码：

async function callLLMWithRetry(payload) {
  const maxRetry = 2;
  let attempt = 0;

  while (true) {
    try {
      return await callLLM(payload);
    } catch (e: any) {
      if (!isRetryableError(e) || attempt >= maxRetry) {
        throw e;
      }
      attempt++;
      await sleep(500 * attempt);
    }
  }
}

2. 降级：模型不可用时要有「备胎」

大模型 API 作为外部依赖，不可能 100% 可用。
因此建议设计「降级方案」：

安全 on Saiga