Next.js部署Cloud Run时环境变量的客户端安全风险咨询

你的判断是正确的，这种部署流程下敏感环境变量不会泄露给客户端，核心原因结合Next.js的环境变量机制和你的构建流程说明如下：

1. Next.js的环境变量暴露规则 #

Next.js仅对**前缀为NEXT_PUBLIC_**的环境变量进行客户端打包注入——只有这类变量会被编译到客户端JS bundle中，供浏览器端代码访问。如果你的Github Secrets没有使用这个前缀，且仅在构建阶段通过next.config.js读取（比如用于配置服务端API密钥、内部服务地址等），这些变量只会存在于服务端构建逻辑或服务端运行时代码中，完全不会出现在客户端产物里。

2. 你的构建流程的安全性 #

• Docker构建阶段的变量隔离：你通过Github Secrets传入Docker的变量，只要在Dockerfile中用ARG而非ENV传递（ARG仅在构建阶段生效，构建完成后不会留存到镜像中），构建完成后镜像里不会残留这些敏感变量。即使你用了ENV，只要这些变量没有被next.config.js以NEXT_PUBLIC_前缀暴露，客户端也无法访问。
• next.config.js的执行时机：这个文件是在构建阶段执行的，它读取的环境变量只会用于生成服务端构建配置（比如自定义路由、服务端API的基础路径），不会直接被客户端代码获取。比如你在next.config.js中写：

  module.exports = {
    env: {
      INTERNAL_API_KEY: process.env.INTERNAL_API_KEY,
    },
  }
  

  客户端代码里尝试访问process.env.INTERNAL_API_KEY会得到undefined，只有服务端代码（如getServerSideProps、API路由）能正常读取这个变量。

关键注意事项 #

• 绝对不要给敏感Secrets添加NEXT_PUBLIC_前缀，哪怕是误操作，否则会直接暴露给所有客户端。
• 优先用Docker的ARG传递构建时变量，避免用ENV把敏感变量留在镜像的运行环境中。
• 区分变量用途：如果是客户端确实需要的公开配置（比如公共CDN地址），才用NEXT_PUBLIC_前缀，这类配置本身不应该包含敏感信息。

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