javascript环境变量需分端安全处理：node.js端用dotenv加载.gitignore保护的.env文件并校验必填项，生产环境改用系统变量；前端仅允许vite_/react_app_/nuxt_public_前缀变量构建时注入，严禁暴露敏感信息。
JavaScript 中读取环境变量本身不难，关键在于“安全地”解析和使用——尤其要区分运行环境（Node.js 服务端 vs 浏览器前端）、避免敏感信息泄露、防止配置误用。核心原则是：后端可读敏感变量，前端只能接触非密钥的公开配置，且必须经构建时注入而非运行时暴露。
Node.js 后端：用 dotenv 安全加载 .env 文件
在服务端，推荐使用 dotenv 加载本地配置，但需严格遵循以下操作：
- 在应用入口文件（如
app.js或index.js）最顶部调用require('dotenv').config()，确保变量在任何业务逻辑前就绪 - 把
.env文件加入.gitignore，绝不提交到代码仓库 - 提供
.env.example作为模板，只含变量名和注释（不含真实值），供团队快速初始化 - 启动时验证必填项，例如：
if (!process.env.DB_PASSWORD) throw new Error('DB_PASSWORD is required') - 生产环境禁用
.env文件，改用系统级环境变量（如 Docker 的env_file、K8s 的Secret或云平台控制台配置）
前端项目（Vue/React/Vite/Nuxt）：仅允许 public 变量构建时注入
浏览器中无法访问系统环境变量，所有变量都由构建工具在打包阶段静态替换。因此必须遵守“前端无密”铁律：
- 变量名必须带约定前缀：
VITE_（Vite）、REACT_APP_（Create React App）、NUXT_PUBLIC_（Nuxt 3）——只有这些前缀的变量才会被注入到客户端 - 像
VITE_API_BASE_URL、VITE_FEATURE_FLAG这类非敏感配置可以安全使用；但VITE_DB_PASSWORD这类写法即使存在也不会进入产物，且应被禁止定义 - 不要试图在前端代码里读取
process.env（它在浏览器中为空或不可靠），统一用框架提供的机制，如import.meta.env.VITE_API_BASE_URL - 敏感逻辑（如鉴权、支付签名）必须由后端 API 承担，前端只传必要参数，不碰密钥、token 签名过程
跨环境一致性：用 NODE_ENV + 配置对象做运行时分发
单纯靠环境变量字符串容易出错，建议封装一层配置对象，按 NODE_ENV 自动合并：
- 定义基础配置
config/base.js，包含通用字段（如日志级别、超时时间） - 按环境拆分
config/development.js、config/production.js，覆盖特定值（如 API 地址、是否启用 mock） - 入口处根据
process.env.NODE_ENV动态导入对应配置模块，再与process.env中的运行时变量（如灰度开关）做浅合并 - 这样既保留环境变量的灵活性，又避免散落各处的
if (process.env.NODE_ENV === 'xxx')判断，提升可读性和测试性
安全红线：哪些绝对不能做
以下行为会直接导致配置失控或信息泄露，务必规避：
- 在前端代码中硬编码 API 密钥、JWT secret、数据库连接串
- 把
.env或含敏感值的 JSON 配置文件部署到 Nginx / CDN 等静态资源服务器上 - 用
console.log(process.env)或将环境变量挂到window对象上供调试 - 在构建脚本中拼接敏感值生成前端代码（如用 shell 脚本 echo 出密钥到 JS 文件）
- 依赖未审核的第三方 dotenv 替代库（如不维护的 fork 版本），可能引入恶意逻辑
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
