网罗开发 （小红书、快手、视频号同名）

  大家好，我是 展菲，目前在上市企业从事人工智能项目研发管理工作，平时热衷于分享各种编程领域的软硬技能知识以及前沿技术，包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。

图书作者：《ESP32-C3 物联网工程开发实战》
图书作者：《SwiftUI 入门，进阶与实战》
超级个体：COC上海社区主理人
特约讲师：大学讲师，谷歌亚马逊分享嘉宾
科技博主：华为HDE/HDG

我的博客内容涵盖广泛，主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告，同时也会提供产品优缺点分析、横向对比，并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。

展菲：您的前沿技术领航员
👋 大家好，我是展菲！
📱 全网搜索“展菲”，即可纵览我在各大平台的知识足迹。
📣 公众号“Swift社区”，每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。
💬 微信端添加好友“fzhanfei”，与我直接交流，不管是项目瓶颈的求助，还是行业趋势的探讨，随时畅所欲言。
📅 最新动态：2025 年 3 月 17 日
快来加入技术社区，一起挖掘技术的无限潜能，携手迈向数字化新征程！

前言

在做前后端分离开发的时候，很多同学都会遇到一个头疼的问题：API 密钥怎么保密？
如果直接把密钥写在前端 JS 代码里，无论你怎么加密、怎么混淆，最终都能被别人通过浏览器调试工具拿到。那怎么办呢？本文就来聊聊常见的解决方案，并结合实际案例写一些可运行的 Demo 代码。

为什么前端存放 API 密钥不安全？

很多初学者喜欢在前端 .env 或者 JS 文件里直接写 API 密钥，比如：

// 错误做法
const API_KEY = "my-secret-api-key";

fetch(`https://api.example.com/data?key=${API_KEY}`)
  .then(res => res.json())
  .then(data => console.log(data));

问题在于，前端代码最终会被打包到浏览器里运行，用户只要打开 F12 调试工具就能看到网络请求里的 key，等于密钥完全裸奔。

所以，我们必须换一种思路：密钥不应该放在前端，而应该交给后端管理。

正确思路：前端不碰密钥，后端来做转发

核心原则其实很简单：

1. 密钥只放在后端安全环境里（比如环境变量、配置文件）。
2. 前端调用自己后端的 API，由后端去请求第三方服务。

这样用户拿到的只是你提供的业务接口，完全接触不到真实的密钥。

举个例子：

后端（Node.js + Express）

// server.js
import express from "express";
import fetch from "node-fetch";

const app = express();
const PORT = 3000;

// 将密钥放到环境变量
const API_KEY = process.env.API_KEY;

app.get("/api/weather", async (req, res) => {
  try {
    // 后端替前端调用第三方 API
    const response = await fetch(`https://api.example.com/weather?key=${API_KEY}`);
    const data = await response.json();
    res.json(data);
  } catch (err) {
    res.status(500).json({ error: "后端调用失败", detail: err.message });
  }
});

app.listen(PORT, () => {
  console.log(`后端服务已启动：http://localhost:${PORT}`);
});

前端（Vue/React 都一样）

// 前端只访问自己后端的接口，不涉及真实密钥
fetch("/api/weather")
  .then(res => res.json())
  .then(data => console.log("天气数据：", data));

这样即便用户打开浏览器抓包，也只能看到 /api/weather 这个接口，拿不到第三方的真实 API Key。

现实场景：为什么一定要这样做？

比如我们做一个大学生实验课的天气查询系统：

• 学生在前端页面点击按钮，查询某个城市的实时天气。
• 如果你把 API Key 直接放在前端，学生就能拿到 Key 去无限调用，甚至滥用。
• 一旦 Key 被泄漏，你的付费额度可能会瞬间被刷爆。

而如果走后端转发：

• 学生的请求都先经过你的后端。
• 你可以在后端加 限流（Rate Limit）、日志监控、用户鉴权 等控制。
• 即使前端代码被扒了，也不会泄漏真正的 Key。

扩展方案：进一步保护密钥

除了最基本的后端代理思路，还可以结合以下方式：

1. 限制来源 IP 或域名：大部分 API 平台支持设置白名单，只允许来自指定后端服务器的请求。
2. JWT 授权机制：前端登录后获取一个临时 Token，带着 Token 请求后端，后端校验后再访问第三方 API。
3. Serverless 云函数：把 API 请求封装在云函数里，比如阿里云/腾讯云函数，前端调用云函数而不是直接调用 API。
4. API Gateway：通过网关统一管理 API 请求和密钥，便于日志和权限控制。

总结

前端分离开发时，API 密钥千万不要放在前端代码里，否则必然会泄漏。正确做法是：

• 把密钥放在后端。
• 前端只调用后端接口，由后端去访问第三方服务。
• 根据场景增加限流、日志、鉴权等机制。

这样不仅能保证密钥安全，还能让整个系统更稳定、更可控。