随着大模型技术的爆发，AI 流式应用（如 ChatGPT、文心一言的实时对话、智能客服、代码补全等）正迅速渗透到日常业务中。这类应用的核心特点是“流式响应”——服务器逐段返回数据，前端即时渲染，带来近乎实时的交互体验。然而，这种模式也给大前端工程师带来了前所未有的安全挑战：如何在前端直接调用大模型 API？如何防止密钥泄露？如何管控用户请求的频率与内容？一种名为 BFF（Backend For Frontend，服务于前端的后端）的架构模式，正成为解决这些问题的关键利器。
流式应用的“双刃剑”
传统 Web 应用中，前端通过 RESTful 请求获取完整响应，安全控制相对简单——令牌验证、HTTPS 加密即可。但 AI 流式应用不同：大模型 API 通常要求使用 API Key 直接调用，而前端 JavaScript 代码完全暴露在浏览器中，一旦将密钥硬编码在客户端，无异于将“后台钥匙”拱手让人。攻击者可以通过抓包工具轻松窃取密钥，进而恶意调用付费 API，导致巨额账单或数据泄露。
此外，流式接口的通信协议多为 Server-Sent Events（SSE）或 WebSocket，前端需要实时处理分段的 JSON 数据。若直接暴露后端流式服务，容易被 DDoS 攻击或遭受 prompt 注入，让模型输出有害内容。因此，大前端工程师必须重构架构：让前端不直接接触大模型服务，而是通过一个可信的中间层进行代理与防护。
BFF：专为前端打造的“安全网关”
BFF 并非新概念，它最早由 SoundCloud 工程师提出，核心思想是“为特定前端客户端单独构建一个后端服务”，负责聚合数据、转换格式、封装底层逻辑。在 AI 流式应用场景中，BFF 层扮演的角色远不止数据代理——它成为一道安全屏障。
具体来说，BFF 服务部署在服务器端（例如 Node.js、Go 或云函数），前端只向 BFF 发送请求，BFF 再携带真实的 API Key 调用大模型供应商的接口。这样，密钥永远保存在服务器环境变量中，前端无从知晓。同时，BFF 可以统一处理身份认证、请求频率限制（Rate Limit）、内容审核等安全策略，为每一路流式连接建立独立的会话上下文。
安全搭建的关键技术实践
要搭建一个安全的 BFF 流式代理，大前端工程师需要掌握三个核心环节：
第一，流式数据的透明转发。 以 SSE 为例，BFF 收到大模型返回的流式数据块后，应立即通过 response.write() 逐块推送给前端，而非缓冲整段再发送。这要求 BFF 使用可读流与可写流管道（pipe），保持低延迟。Node.js 的 EventSource 和 fetch 流式 API 是实现这一目标的基础。
第二，认证与授权拦截。 在 BFF 层接入 JWT 或 OAuth 令牌验证，确保只有登录用户才能发起流式请求。同时引入基于用户维度的令牌桶算法，限制单个用户每分钟可发送的 token 数，防止恶意刷量导致 API 成本失控。
第三，内容安全过滤。 利用正则或第三方审核接口，在流式文本到达前端之前，实时检测并拦截包含敏感词、恶意代码或 prompt 注入企图的内容。例如，在 BFF 中设置黑名单关键词，当检测到用户输入试图“打破角色设定”或“获取系统提示词”时，立即终止连接并记录日志。
实战案例：智能客服的安全改造
某电商平台曾遇到严重问题：前端直接接入 OpenAI 的 API，导致测试环境密钥被爬虫截获，一天内产生数十万元费用。随后，团队引入 BFF 层：使用 Next.js API Routes 作为 BFF 服务，前端仅发送用户 ID 和消息文本。BFF 首先校验用户登录态，然后通过环境变量获取 API Key，调用流式接口，同时利用 stream-json 库解析数据，在转发的过程中对敏感字段（如用户手机号）进行脱敏替换。改造后，密钥安全性得到保障，前端代码中不再出现任何 API 端点信息，攻击面大幅收窄。
结语：BFF 是 AI 原生应用的“必选项”
大模型时代，前端工程师不再只是“切图仔”或“UI 交互实现者”，而是需要深入理解网络协议、安全策略和系统架构的“全栈工程师”。BFF 架构以其轻量、灵活、与前端紧密耦合的特点，完美契合了 AI 流式应用对低延迟与高安全性的双重需求。对于任何想要在生产环境中安全落地 AI 功能的大前端团队来说，搭建一个可靠的 BFF 层，已是必修课。未来，随着边缘计算和 WebAssembly 的发展，BFF 还将进一步下沉到 CDN 节点，实现更极致的响应速度——但安全，永远是这条流式管道的第一道阀门。