环境变量文件应按用途命名：.env.development、.env.production；vite需显式指定mode；仅特定前缀变量（如react_app_、next_public_）暴露至前端；dotenv须在业务代码前调用且路径准确；ci/cd应使用平台密钥管理而非文件；docker避免--env-file泄露；electron/nuxt等需专用方案确保变量注入。

环境变量文件怎么命名才不踩坑

Node.js 和多数现代框架（如 Next.js、Nuxt、Vite）默认读取 .env，但开发和生产必须隔离——靠文件名区分是最直接、最不易出错的方式。

• .env.development 仅在 npm run dev 或 process.env.NODE_ENV === 'development' 时加载
• .env.production 在 npm run build 或 NODE_ENV=production 下生效
• 不要用 .env.local 存敏感配置：它会被 Git 忽略，但若误提交或 CI 环境没清理，极易泄露
• Vite 中 .env.staging 不会自动加载，必须显式指定 mode: 'staging' 启动参数

如何让 process.env 真正生效而不是 undefined

环境变量不会自动注入到运行时代码里。Webpack/Vite/Next.js 都只把以 VUE_APP_、REACT_APP_、NEXT_PUBLIC_ 开头的变量暴露给浏览器端；服务端代码可读全部，但需确认构建阶段是否已注入。

• React 项目中写 process.env.API_BASE_URL → 一定是 undefined，必须改成 process.env.REACT_APP_API_BASE_URL
• Next.js 中只有 NEXT_PUBLIC_ 前缀的变量能在客户端组件里访问，服务端组件可直接读 process.env.DB_HOST
• Node.js 服务端若用 dotenv，要确保 require('dotenv').config({ path: '.env.production' }) 在所有业务代码前执行，且不能依赖 import 顺序

CI/CD 里怎么安全传入生产密钥

本地 .env.production 绝对不能进 Git，但 CI 流水线需要这些值。硬编码在 YAML 里是高危操作，正确做法是平台级密钥管理。

• GitHub Actions：用 secrets 对象传值，再映射为环境变量：DB_PASSWORD: ${{ secrets.DB_PASSWORD }}
• Vercel / Netlify：在项目设置页手动添加环境变量，它们会在构建和运行时自动注入，无需额外配置文件
• Docker 构建时别用 --env-file .env.production：该文件可能被 COPY 进镜像，导致密钥泄露；改用 docker run -e DB_HOST=... 或 docker-compose.yml 的 environment: 字段

为什么 dotenv 在 Electron 或 SSR 场景下容易失效

Electron 主进程和渲染进程是两个 Node.js 实例；SSR 框架如 Nuxt 的服务端和客户端打包路径不同，dotenv 加载时机稍有偏差，变量就丢了。

• Electron 渲染进程默认无 Node.js 环境，process.env 是空对象，必须用 contextIsolation: false + nodeIntegration: true（不推荐），或改用 IPC 从主进程传配置
• Nuxt 3 的 useRuntimeConfig() 是唯一可靠方式，它把服务端变量序列化后注入页面，避免直接读 process.env
• Webpack 的 DefinePlugin 可以全局替换字符串，但注意它只是编译期文本替换：API_URL 写死成 'https://prod.api.com'，无法动态切换

多环境配置真正的复杂点不在写法，而在「谁在什么时候、以什么权限、往哪个上下文里塞了哪部分变量」——漏掉任意一环，process.env 就是空的，而且错误往往不报错，只默默用错地址或超时。