变量的可见性、生命周期和访问方式受模块化与封装机制约束。模块化通过边界定义作用域，封装通过接口控制访问，二者协同解决命名冲突、状态污染等问题。
变量在程序结构中不是孤立存在的，它的可见范围、生命周期和访问方式，直接受模块化与封装机制的约束。理解这一点，才能避免命名冲突、数据误改、作用域混乱等问题。
变量的可见性由模块边界决定
模块化把代码按功能划分为独立单元，每个模块拥有自己的作用域。变量定义在哪个模块里，就默认属于那个模块的私有空间。
- 在 JavaScript 的 ES6 模块中，用 const/let/var 声明的顶层变量不会自动挂到全局，必须显式 export 才能被其他模块使用
- 在 C++ 或 Java 中，变量若声明在类内部且标记为 private，即使同属一个编译单元，也无法被外部直接访问
- 函数内部声明的变量（如 let x = 1）天然受限于函数作用域，这是最基础的模块化体现——以函数为最小隔离单位
封装让变量从“可读可写”变成“可控访问”
封装不是否认变量的存在，而是重新定义它和外界的关系：不暴露原始字段，而是通过接口间接操作。
- 比如 Java 中把 int age 设为 private，再提供 getAge() 和 setAge(int a) 方法，就能在 setter 中加入校验逻辑（如禁止负数）
- C# 的属性（public int Age { get; set; }）表面像字段，实际是编译器生成的 getter/setter 方法，便于后期增强控制
- JavaScript 中可用闭包模拟私有变量：function createCounter() { let count = 0; return { increment() { count++; }, value() { return count; } }; } —— 外部永远无法绕过方法直接修改 count
模块化 + 封装共同解决变量管理的典型问题
单靠作用域或访问修饰符都不够，二者配合才能应对真实开发场景。
- 配置变量重复加载：把数据库连接字符串等配置提取为独立模块（如 config.js），并封装成只读对象或带缓存的 getter，避免多处 import 导致多次解析
- 状态污染：UI 组件中维护的 loading 状态，应封装在组件实例内部（如 React 的 useState 或 Vue 的 data），而非散落在全局变量里
- 跨模块共享需明确契约：两个模块要共用用户信息，不应各自定义 user 变量，而应由认证模块统一导出 currentUser 对象，并规定其结构和更新方式
别把“声明变量”当成“组织变量”的终点
写 let data = [] 很容易，难的是想清楚：它该在哪声明？谁有权改它？生命周期多长？变化时要不要通知别人？这些问题的答案，不在语法层面，而在模块划分和封装设计里。
