题库规划 / 07-全栈端侧与权限审计
← 上一章 下一章 →

07 - 全栈端侧与权限审计实践篇

核心定位：全栈闭环交付、微信小程序端流式渲染优化、Web 运营管理端、统一身份认证（SSO/OAuth）、数据级 RBAC 与全链路合规审计。

Q1: 作为全栈开发者，你是如何规划和落地微信小程序端与 Web 管理端的技术选型与架构设计的？

回答（求职者口吻）：
为了实现高效交付并保证跨端体验的一致性，我对两端做了明确的架构分工与选型：

  1. 微信小程序端（面向终端使用者 - 强调轻量、即时、流畅）：
    - 选型：采用原生微信小程序框架 / Uni-App + TypeScript。
    - 核心职责：轻量化多轮流式对话、语音/文字双模输入、引用角标弹出卡片、PDF 预览翻页、Agent 进度条实时展示。
    - 重点攻坚：流式 Token 高频渲染下的页面不卡顿、长列表内存回收、网络断线静默重连。
  2. Web 管理端（面向知识专家与管理员 - 强调富交互、专业、高吞吐）：
    - 选型：Vue 3 / React + TypeScript + Element Plus / Ant Design。
    - 核心职责：文档批量上传与 OCR 纠偏、知识分块可视化微调、租户与组织权限矩阵配置、Agent 运行 DAG 轨迹审计、运营大屏监控。
    - 重点攻坚：大文件切片上传、复杂表格多维度筛选、PDF 页面高亮 BoundingBox 坐标渲染。
  3. 前后端契约统一：
    - 使用 OpenAPI / Swagger 定义统一接口规范，结合自动化工具生成 TypeScript DTO 类型定义，彻底消除前后端字段不一致导致的联调内耗。

Q2: 微信小程序在实现大模型流式输出（打字机效果）、Markdown 实时渲染及长列表滚动时，遇到了哪些性能瓶颈？如何优化的？

回答（求职者口吻）：
微信小程序的双线程渲染架构（Logic Thread 与 View Thread 之间通过 setData 跨线程通信）在流式场景下极易遇到性能瓶颈：

  1. setData 高频调用导致线程阻塞与掉帧（核心痛点）：
    - 大模型一秒可能吐出 15~30 个 Token，如果每个 Token 都调用一次 setData，通信管道会迅速被挤爆，导致界面严重掉帧、打字机卡顿。
    - 优化方案（时间切片节流与局部更新）：在小程序端维护一个本地字符队列，采用 requestAnimationFrame 或 50ms 节流定时器批量合并字符，只有当收集满一批 Token 或到达时间切片时，才触发一次 setData；并且只对当前最新消息节点的 content 字段进行路径级更新（如 setData({ ['messages[' + index + '].content']: newContent })），避免全量序列化整张消息列表。
  2. 长 Markdown 流式实时解析卡顿：
    - 边生成边全量编译 Markdown 会消耗大量 CPU。我们采用增量正则解析器，流式生成期间仅渲染纯文本与简易加粗/换行，待收到 [DONE] 结束事件后，再触发一次完整的富文本 Markdown 编译，极大提升了生成过程中的平滑度。
  3. 长列表虚拟滚动与内存回收：
    - 会话历史超过 50 条时，启用虚拟列表（Virtual List）或动态回收可视区外的 DOM 节点，避免小程序内存超限闪退。

Q3: 政务系统通常使用统一身份认证（如政务微信 OAuth、单点登录 SSO、CA 证书认证），你们后端是如何做统一身份对接与 Token 签发的？

回答（求职者口吻）：
政务环境通常存在集中式的统一身份认证中心（IAM / SSO），我们采用了“前置 SSO 协议适配 + 内部自签无状态 JWT”的双层令牌架构：

  1. 统一认证接入与身份置换（Identity Exchange）：
    - 小程序端：用户通过政务微信 wx.login 获取 code，后端凭 code 向政务微信服务端换取用户唯一的 openid / userid，并关联内部政务人员档案。
    - Web 端：对接政务内网的 OAuth 2.0 / CAS / SAML 2.0 单点登录系统。用户在统一登录页认证成功后，携带 Auth Code 回调至我们系统的 Auth Gateway。
  2. 内部安全 JWT 签发：
    - 业务后端验证通过后，不直接使用外部 Token，而是签发系统内部标准的非对称加密 JWT（RS256 签名）。
    - JWT Payload 包含：user_id、tenant_id、org_id（所属科室组织链）、roles（角色列表）、security_level（个人涉密等级）及全局唯一的 jti（Token ID 用于黑名单注销）。
  3. 无状态验签与上下文透传：
    - 后端各微服务仅需加载 Auth 服务的公钥即可在本地快速验签，无需频繁反查认证中心，兼顾了安全性与高性能。

Q4: 详细讲讲你们的权限设计：如何实现基于 RBAC 的租户、组织、科室和数据资源级的细粒度权限控制？

回答（求职者口吻）：
我们构建了“多租户隔离 + 树形组织继承 + 资源级 RBAC”的立体权限模型：

  1. 多租户（Tenant）硬隔离：
    - 不同的委办局（如市发改委、市经信局）属于独立 Tenant，数据在逻辑与存储层面完全隔离。
  2. 树形组织机构（Tree-based Organization RBAC）：
    - 组织架构呈树状（局机关 -> 各业务处室 -> 各基层科室）。部门具备 org_path（如 /1/5/12/）。在权限继承上，上级处室领导默认具备向下穿透查看下级科室公开知识库的权限。
  3. 数据资源级权限控制（Resource-Level Access Control）：
    - 权限不仅控制到“能否访问某个菜单”，更深入到“能否检索某篇具体公文”：
    • 公开级（Public）：全员可检索；
    • 部门级（Department-Only）：仅允许 org_id 匹配或在其子树范围内的用户检索；
    • 密级限制（Confidentiality Level）：用户的 security_level 必须大于等于文档设定的 doc_secret_level。

Q5: 知识库文件和问答中的敏感数据如何进行数据权限管控？在 RAG 检索层是如何实现数据级物理过滤的？

回答（求职者口吻）：
在 RAG 问答中，绝对不能把所有文档检索出来后再在应用层过滤，因为这会导致相关度计算被污染且存在漏报风险。我们在 RAG 检索层实现了“前置元数据强制过滤（Pre-Filtering）”：

  1. 向量索引阶段注入权限元数据：
    - 每个 Chunk 在写入向量数据库（Milvus/Infinity/Elasticsearch）时，同时打上不可篡改的权限标签：tenant_id、allowed_org_ids（数组）、min_security_level。
  2. 检索查询构造期动态拼接 Filter 表达式：
    - 当用户发起提问时，Go 业务层从不可篡改的 Context 中提取当前用户的权限特征，在构造发往 RAGFlow / 向量引擎的 DSL 查询语句时，强制附加过滤条件：
    json { "filter": "tenant_id = 'T1001' AND (is_public = true OR allowed_org_ids IN ['ORG_5', 'ORG_12']) AND min_security_level <= 2" }
  3. 结果保证：
    - 向量检索与 BM25 仅在用户有权访问的候选文档子集中计算相似度与排序。无权查看的涉密文件在物理检索层面直接被完全排除，从根本上杜绝了越权查看与数据泄露。

Q6: 全链路安全审计（Audit Log）在系统中是如何落地的？记录了哪些维度的信息？如何保证不可篡改？

回答（求职者口吻）：
按照政务与网络安全等级保护（等保三级）要求，我们建立了全方位的“事前记录、事中存证、事后可溯”的审计系统：

  1. 审计日志维度（Audit Schema）：
    - 主体信息：操作人 ID、姓名、所属科室、客户端 IP、设备指纹、政务微信 OpenID。
    - 客体信息：访问的知识域、触发的业务模式（Chat / Agent）、调用的工具名称、操作类型（检索/问答/导出/删除）。
    - 内容存证：原始提问 Query、改写后的 Query、命中的参考 Chunk 列表及文档 ID、大模型完整生成文本、Token 消耗及响应耗时。
  2. 审计流水线异步解耦：
    - 审计日志通过内存队列异步写入专用审计表与只读日志存储，绝不阻塞核心业务主流程。
  3. 防篡改与安全合规存储：
    - 审计表在数据库层面剥离了 UPDATE 和 DELETE 权限，仅允许 INSERT；
    - 定期将审计日志同步至只读归档介质，保留时间严格大于 180 天，满足网信部门和等保标准的溯源核查要求。

Q7: 微信小程序在对接后端 SSE 流式长连接时，使用了什么原生 API？踩过什么网络坑？

回答（求职者口吻）：
微信小程序不支持标准浏览器的 EventSource 对象，我们采用了小程序底层的 wx.request 流式分块接收 API（enableChunked: true）：

  1. 核心实现细节：
    ```javascript
    const requestTask = wx.request({
    url: ‘https://gov-api.xxx.com/api/v1/chat/stream’,
    method: ‘POST’,
    data: { query: ‘…’, session_id: ‘…’ },
    enableChunked: true, // 开启分块接收
    header: { ‘Authorization’: ‘Bearer ’ + token },
    success: (res) => { … }
    });

// 监听二进制/文本分块数据流
requestTask.onChunkReceived((response) => {
const arrayBuffer = response.data;
const text = decodeUtf8(arrayBuffer); // 处理 UTF-8 解码与分包粘包
parseSseEvents(text); // 状态机解析 SSE 事件
});
` 2. **踩坑与排障实战**： - **UTF-8 字符跨包截断导致乱码（粘包/半包）**：一个中文字符在 UTF-8 中占 3 个字节。网络分包可能把这 3 个字节切分在两个 Chunk 中，直接 `decode` 会出现 乱码。解决方案：使用 TextDecoder('utf-8', { stream: true }) 维护流式解码状态，自动缓存不完整的字节序列。
- 后台挂起断连：用户切出微信时小程序会被挂起，iOS/Android 会主动终止 TCP 连接。我们在端侧监听 onAppHide 与 onAppShow，切回前台时自动拉取最新会话历史进行断点状态同步。

Q8: Web 管理端在展示复杂 Agent 任务 DAG 执行图、任务步骤时间轴和文档分块高亮时，是如何做组件化抽象与性能优化的？

回答（求职者口吻）：
在 Web 端，我们针对复杂的 AI 可视化场景构建了专门的组件库：

  1. PDF 页面与分块高亮渲染器（PDF Chunk Highlighter）：
    - 基于 PDF.js 封装。将文档视口与 Canvas 渲染层解耦，通过 CSS 绝对定位层在 PDF 上绘制半透明 SVG 矩形框。针对高分辨率大文档，只渲染当前可视区域的页面（按需懒加载），有效避免浏览器内存崩溃。
  2. Agent 执行步骤时间轴与 DAG 状态机组件：
    - 将 Agent 的每个 Step 抽象为统一的 Card 容器，定义 Standard Props：status (pending/running/success/error)、toolIcon、costTime、paramsSummary 和 resultRenderer。
    - 利用动态组件（Dynamic Component / Slot）根据不同工具类型渲染不同的内容卡片（如检索工具渲染文档列表、对比工具渲染 Diff 矩阵）。
  3. 数据响应式性能优化：
    - 避免将超大的原始文档分块数据放入 Vue 的深度响应式 ref / React 的高频 useState 中，使用 shallowRef / useRef 存储只读数据，减少 Proxy 拦截开销。

Q9: 前后端接口交互中，如何防御常见的安全攻击（XSS、CSRF、接口防重放、越权访问 IDOR）？

回答（求职者口吻）：
结合我 6 年的安全背景，我们在系统的各层建立了纵深防御体系：

  1. 防 XSS（跨站脚本攻击）：
    - 大模型生成的 Markdown 文本中可能被注入恶意 <script> 或 <iframe> 代码。前端在富文本渲染前必须经过 DOMPurify 严格消毒过滤；后端在入库与出库阶段对 HTML 标签进行实体编码转义。
  2. 防 CSRF（跨站请求伪造）：
    - 系统全面采用基于 Header 的 Authorization: Bearer <JWT> 机制，不使用浏览器默认 Cookie 存储 Session，天然免疫 CSRF 攻击；同时配置严格的 CORS 域名白名单。
  3. 防越权访问（IDOR - 不安全的对象直接引用）：
    - 严禁直接使用客户端传递的 tenant_id 或 org_id。所有涉及数据查询的接口（如拉取会话详情 GET /api/session/:id），后端强制校验该 id 对应的记录中的 user_id / tenant_id 是否与当前 JWT 中的主体一致，杜绝遍历 ID 水平越权。
  4. 接口防重放与防刷：
    - 关键写入接口要求携带 Nonce（随机数）与 Timestamp，后端基于 Redis 校验时间戳窗口（±60秒）与 Nonce 唯一性，防止请求被截获重放。

Q10: 作为独立负责双端交付的全栈工程师，你在保证工程质量、前后端契约协同与跨端联调方面有什么最佳实践？

回答（求职者口吻）：
独立负责全栈交付的核心优势在于“沟通链路极短，端到端反馈极为迅速”，但更需要严谨的工程化机制来防止技术债务：

  1. 契约先行（Schema-First Design）：
    - 在写业务代码前，首先定义严格的 API 数据结构（Swagger/OpenAPI/Proto）。使用工具自动生成前后端通用的 TypeScript Interface 和 Go Struct，确保接口字段、枚举值完全对称，绝不依靠口头约定。
  2. 模块化与关注点分离（Separation of Concerns）：
    - 前端严格分离“API 请求层”、“状态管理层（Pinia/Redux）”与“UI 纯渲染组件”；后端严格分离“路由参数层”、“业务逻辑 Service”与“数据库 DAO”。即使由单人开发，代码结构依然清晰规范。
  3. 自动化测试与质量门禁（Quality Gates）：
    - 编写关键业务路径的单元测试（Go 表格驱动测试、前端核心组件渲染测试），接入 GitLab CI 流水线自动化运行 Lint 和 Test，保障每次代码提交的稳定可靠。