环境变量文件应按用途命名：.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 就是空的，而且错误往往不报错，只默默用错地址或超时。
