Next.js的.env文件变量是否会暴露给前端用户？

关于NEXT_PUBLIC_前缀变量的暴露问题 #

• 官方文档提到的「暴露给浏览器端」是实打实的风险：所有带NEXT_PUBLIC_前缀的环境变量，会在项目构建阶段被直接硬编码写入下发给用户的客户端JS包中。任何访问你站点的用户，只要打开浏览器开发者工具，查看静态加载的JS资源、或者在控制台直接读取对应process.env字段，就能拿到完整的变量值，没有任何隐蔽性。
• 绝对不要给Mux私钥、Firestore Admin SDK凭据、数据库连接串这类敏感配置加这个前缀。

服务端读取环境变量的安全性 #

• 只要你把敏感环境变量的读取、相关业务逻辑全部放在服务端侧执行，就不会出现变量泄露问题。Next.js不会把不带NEXT_PUBLIC_前缀的变量打包进客户端资源，这类变量只会存在于服务端运行时，用户完全接触不到。
• 符合安全要求的服务端运行场景包括：Pages Router下的getServerSideProps/getStaticProps服务端逻辑、pages/api下的接口路由、App Router下的Server Component、Route Handler、服务端运行的中间件逻辑。

前端组件中直接读取dotenv变量的风险 #

• 分两种情况判断：
  1. 如果你在前端组件中读取的是带NEXT_PUBLIC_前缀的变量：不管是直接通过process.env读取还是手动引入dotenv包加载，最终变量值都会被注入客户端JS包，访问站点的用户可以直接获取到对应值。
  2. 如果你在前端组件中读取的是不带NEXT_PUBLIC_前缀的服务端变量：Next.js构建阶段会直接把客户端代码中引用的这类变量替换为undefined，你在前端根本读不到有效值，自然也不会出现泄露——构建工具从根源上就不会把这类敏感变量写入客户端资源。

实操提示：Firestore面向客户端的Web SDK初始化配置本身就是设计为可公开暴露的（权限靠Firestore安全规则管控），这类配置可以加NEXT_PUBLIC_前缀在前端使用；但涉及服务端调用的密钥类配置，必须放在服务端逻辑中读取使用。

内容的提问来源于stack exchange，提问作者Yihan Duan