模块化系统通过封装明确变量边界、防止意外耦合，各语言均默认限制跨模块访问，需显式声明（如Java的exports/opens、Rust的pub、C的宏控制、Node.js的配置传参）才能合规暴露。
模块化系统对变量可见性的限制，本质是封装机制的体现——它不是为了制造障碍，而是为了明确边界、防止意外耦合。不同语言的模块系统实现方式不同，但核心逻辑一致：变量默认不可跨模块访问，必须通过显式声明才能“被看见”。突破限制的关键不在于绕过规则，而在于理解并正确使用各语言提供的合规路径。
Java模块系统（JPMS）：exports与opens缺一不可
在Java 9+中，仅把类声明为public远远不够。若一个类位于com.example.util包中，并标注了@Service，其他模块仍无法加载它，除非：
- 提供方模块在
module-info.java中写明：exports com.example.util; - 消费方模块声明依赖：
requires com.example.util; - 若框架需反射访问私有字段（如Jackson序列化内部状态），还需：
opens com.example.util;——注意opens和exports语义不同，前者专为反射开放，后者面向编译期类型引用
Rust模块系统：pub控制粒度，use简化引用
Rust中没有全局变量概念，所有项默认私有。可见性由pub逐级控制：
-
pub fn：函数可在父模块外调用 -
pub(crate) struct Config：结构体仅对当前crate可见，比pub更收敛 -
pub use可重新导出子模块内容，形成公共API入口 - 跨文件使用时，需用
use crate::utils::math::add;或在mod.rs中统一导出，避免路径冗长
C语言静态函数：测试场景下的安全暴露
static函数本意是限制作用域，但单元测试需要调用验证逻辑。可行且低风险的做法包括：
- 预处理器宏控制：
#ifdef UNIT_TESTING #define static #endif，仅在测试编译时解除限制 - 头文件中声明函数指针类型，源文件内将
static函数地址赋给该指针，测试代码通过指针调用 - 不推荐直接删掉
static——会破坏接口契约，导致链接冲突或命名污染
Node.js模块作用域：无法注入局部window的原因
JavaScript词法作用域决定了模块内对window等标识符的解析发生在定义时，而非运行时调用时。因此：
- 在函数内定义
const window = {}，对require("@braze/web-sdk")完全无效 - 该SDK内部的
window引用必然指向全局对象，或抛出ReferenceError - 真正可行的替代方案是：使用SDK支持的初始化配置参数传入上下文，或改用支持沙箱环境的SDK版本
