全局变量传参的实用技巧与避坑指南

写代码时，函数之间传递数据是家常便饭。有时候图省事，直接用全局变量传参，看似方便，实则暗藏隐患。但也不能一棒子打死，有些场景下它确实能快速解决问题。

什么时候会用到全局变量传参

比如做一个简单的网页计数器，用户每点击一次按钮，数字加一。如果把这个计数器的值放在某个函数内部，每次调用都会重置。这时候把它提到全局作用域，多个函数都能读取和修改，问题就解决了。

let count = 0;

function addOne() {
    count++;
    document.getElementById('counter').innerText = count;
}

function resetCount() {
    count = 0;
    document.getElementById('counter').innerText = count;
}

两个函数共享同一个 count 变量，不需要来回传参数，逻辑清晰。这种简单脚本里，全局变量用起来顺手。

但问题往往出在“太方便”上

项目一大，多人协作，谁都能改全局变量，追踪 bug 就像找一根看不见的线。比如有个同事在另一个文件里写了 count = null，你这边突然报错，查半天才发现是值被意外清空了。

再比如做页面权限控制，用一个全局变量 isAdmin 判断是否显示管理按钮。开发阶段手动设为 true 测试没问题，结果忘了删，上线后所有人都能看到管理入口，这就出大事了。

替代方案更稳当

把数据封装成模块，通过明确的接口暴露出去，既能共享状态，又能控制修改权限。

const UserState = {
    _isAdmin: false,

    get isAdmin() {
        return this._isAdmin;
    },

    setAdmin(status) {
        if (typeof status === 'boolean') {
            this._isAdmin = status;
        }
    }
};

// 使用
UserState.setAdmin(true);
console.log(UserState.isAdmin); // true

这样一来，外部不能随意篡改 _isAdmin，必须走 setAdmin 方法，还能加校验逻辑。比裸露一个全局变量安全多了。

真要用，也得有点规矩

如果实在绕不开全局变量，至少做到三点：命名带前缀、集中声明、注释清楚用途。比如所有全局配置都以 g_ 开头：g_userInfo、g_apiHost，一眼就知道是全局的，不容易误撞。

还有就是尽量只读不写。配置类信息可以全局访问，但运行中的状态别乱放。像 API 地址、默认超时时间这类不变的值，放全局没问题；但用户登录状态、表单数据这些动态的，还是交给专门的状态管理工具更靠谱。