关于node配置全局变量，先给你一个可以直接用的结论
在Node.js中配置全局变量，最推荐的方式是使用global对象或环境变量文件（如.env），前者适合跨模块共享数据，后者适合保护敏感配置信息。
很多同学在开发Node项目时都遇到过这种场景：明明在A文件里定义了一个变量，到了B文件里却拿不到；或者数据库密码、接口密钥这些敏感信息散落在代码各处，改起来麻烦还容易泄露，这些问题本质上都是全局变量配置策略没做好，接下来我按不同的使用场景，把Node配置全局变量的几种主流方式拆开讲清楚。
用global对象实现跨模块共享
这是Node最原生的全局变量方案。global在Node环境里相当于浏览器里的window，任何挂载在global上的属性，在整个进程的生命周期内都可以直接访问。
挂载和取值的基本操作
在入口文件（比如app.js）里这样挂载：
// app.js
global.config = {
appName: '我的应用',
version: '1.0.0',
port: 3000
};
然后在任意其他模块里直接访问：
// user.js console.log(global.config.appName); // 输出：我的应用 console.log(config.version); // 输出：1.0.0（global属性可以省略global前缀）
实际操作中,建议在项目入口文件的最顶部完成挂载，确保其他模块require进来时变量已经存在，如果分散在多个文件里挂载，执行顺序一旦错乱，很容易出现undefined的诡异问题。
什么时候用global，什么时候别用
行业共识认为,global适合放一些不常变动的业务配置，比如应用名称、版本号、日志级别开关等，但有两类东西千万别往里放：
- 用户请求相关的数据，多个请求会并发执行，往
global里塞用户ID或者临时状态，会造成数据串线，这是大忌。 - 敏感密钥，挂在
global上的属性，代码里每个角落都能访问，一旦某个第三方库被注入恶意代码，密钥直接暴露。
如果你要配置的是数据库连接、文件路径、外部服务地址这类环境相关的变量，再纠结一下，global不是最优解，继续往下看。
用.env环境变量文件管理敏感配置
这才是生产环境里node配置全局变量的主流做法，通过dotenv这个库，把配置项写进.env文件，然后在代码里用process.env读取。
具体操作步骤
先用npm安装依赖：
npm install dotenv
在项目根目录创建.env文件：
DB_HOST=localhost
DB_PORT=5432
DB_USER=root
DB_PASSWORD=mysecretpassword
JWT_SECRET=this_is_a_very_long_random_string在入口文件第一行加载并配置：
// app.js
require('dotenv').config();
const dbPort = process.env.DB_PORT;
console.log(`数据库端口：${dbPort}`);
注意,.env文件里读出来的值都是字符串，如果你期望的是一个数字或布尔值，记得手动转换：
const port = Number(process.env.PORT) || 3000; const isProd = process.env.NODE_ENV === 'production';
强烈建议把.env加入.gitignore
这是很多人容易忽略的关键一步,把.env提交到Git仓库，相当于把数据库密码和密钥直接晒在GitHub上，在.gitignore文件里加上一行：
.env同时提供一个.env.example文件提交到仓库，里面只写变量名和示例值，比如DB_PASSWORD=changeme，方便其他开发同学快速了解需要配置哪些项。
本地配置和线上配置可以分开管理
实际项目里,本地和线上的配置大概率不一样，你可以用.env.development和.env.production区分环境，然后通过dotenv指定加载哪个文件：
NODE_ENV=production node app.js
代码里做对应判断：
const env = process.env.NODE_ENV || 'development';
require('dotenv').config({ path: `.env.${env}` });
这种方式在多环境部署场景下非常实用,比如你买了一个便宜的云服务器跑测试，生产环境用另一台高配机器，两边配置互不干扰。
用config模块整合复杂配置结构
当项目规模上来之后,配置项可能有几十个，甚至存在嵌套对象，这时候global和.env都会显得力不从心，node-config这个模块可以优雅地解决结构复杂和环境切换的问题。
安装和目录结构
npm install config
项目根目录新建config文件夹，结构大概长这样：
config/
├── default.json
├── development.json
├── production.json
└── custom-environment-variables.jsondefault.json放公共配置：
{
"app": {
"name": "我的应用",
"port": 3000
},
"db": {
"host": "localhost",
"options": {
"poolSize": 10
}
}
}
development.json和production.json
里，只需要写和默认值不同的项，
// production.json
{
"db": {
"host": "prod-db-server.internal",
"options": {
"poolSize": 50
}
}
}
读取配置的方式
代码里这样用：
const config = require('config');
const appName = config.get('app.name');
const poolSize = config.get('db.options.poolSize');
console.log(appName); // 我的应用
console.log(poolSize); // 开发环境读default的值10，生产环境读50
config模块会根据NODE_ENV自动决定加载哪个环境的配置文件，不用在代码里写一堆if else，它还支持把敏感值映射到环境变量，具体做法是配置custom-environment-variables.json，让某个配置项从process.env里取值，兼顾了灵活性和安全性。
三种方式的对比与适用场景
| 配置方式 | 适用规模 | 敏感信息支持 | 环境切换 | 推荐度 |
|---|---|---|---|---|
global对象 |
小型项目、简单常量 | 不推荐 | 不友好 | 临时用 |
.env + dotenv |
中型项目 | 很好 | 需要自己处理 | 日常首选 |
node-config |
大型项目 | 需要配合环境变量 | 自动切换 | 工程化推荐 |
如果你的项目规模不到一万行代码，用dotenv就足够了，折腾node-config反而增加复杂度。如果项目涉及多套环境、配置项超过20个，直接上node-config，省心很多。
实操中容易踩的坑
挂载时机晚于使用时机
有同学把global.config的赋值语句写在某个工具模块里，然后入口文件先require了另一个依赖该配置的模块，结果运行时报错，解决办法只有一个：全局变量的初始化放在入口文件所有业务代码之前。
代码里直接写死路径
最常见的反面案例：
const filePath = '/home/user/project/uploads';
这种配置放在全局变量里管理是必须的,但很多人图省事直接写，如果服务器上项目路径变了，或者从Windows换到Linux开发，全得改一遍，正确姿势是把路径放进配置文件，用path.join或者path.resolve基于__dirname动态拼接。
频繁修改后不重启
Node的require有缓存机制，配置文件修改后需要重启Node进程才能生效，不会热更新，如果你在自己电脑上开发，用node app.js直接跑，改完配置记得重启，如果有自动化部署工具，配置改动会触发服务重启，这倒是问题不大。
一个完整的综合示例
结合.env和global的实际用法，给一个可以直接拿来改的示例：
// app.js
require('dotenv').config();
global.APP_CONFIG = {
env: process.env.NODE_ENV || 'development',
port: Number(process.env.PORT) || 3000,
db: {
host: process.env.DB_HOST,
user: process.env.DB_USER,
password: process.env.DB_PASSWORD
}
};
// 业务代码里直接使用
// console.log(APP_CONFIG.db.host);
.env文件：
NODE_ENV=development
PORT=3000
DB_HOST=127.0.0.1
DB_USER=root
DB_PASSWORD=123456这套组合拳,日常开发完全够用。
全局变量和本地变量的取舍
很多Node初学者写代码时,习惯把什么都挂到global上，图省事，但业内专家指出，全局变量的滥用会带来两个问题：一是模块之间的隐式依赖增多，排查问题靠猜；二是测试困难，mock数据时很难覆盖所有模块，写代码时多问自己一句：这个变量真的需要全局可见吗？如果只是单个模块内部用，用const定义在模块顶部就够了。
核心结论就一句话：能用环境变量解决的问题，不要用全局对象；能用模块级变量解决的问题，不要升级成全局状态。 环境变量负责敏感数据和多环境差异化配置，global负责必须在整个进程共享的少量常量，搞清楚了这两者的边界，node配置全局变量这件事就算真正吃透了。
关于node配置全局变量的常见疑问
问：为什么global.xxx在有些模块里访问不到？
大概率是挂载的代码还没执行,其他模块就先被加载了，Node的模块加载是按require顺序同步执行的，确保在入口文件最顶部，所有其他require之前挂载全局变量，另外检查一下赋值语句是否有条件判断被跳过了。
问：使用.env文件时，变量名有什么规范吗？
变量名建议全部大写,用下划线分隔单词，比如DB_HOST、JWT_SECRET，这是社区普遍接受的约定，团队协作时不容易看花眼，还有一点，变量值如果包含或空格，需要用双引号包裹，否则解析会出错。
问：生产环境有专门的配置中心，比如K8s里的ConfigMap，还需要用node-config吗？
如果你已经在用Kubernetes这类容器编排平台,ConfigMap或者Secret挂载的方式比node-config更贴近基础设施层，但当应用内部的启动逻辑仍然需要根据环境读取不同参数时，dotenv和node-config的价值依然存在，实际项目里，两者可以共存：外部基础设施管密钥和地址，应用内部用node-config整合业务相关的配置参数。