静态校验指在代码加载或编译阶段检查模块导入导出标识符是否存在及拼写是否正确，可精准拦截因命名错误导致的ReferenceError等异常，将问题暴露在开发早期。
静态校验在模块系统中，是指在代码加载或编译阶段（而非运行时）就检查模块导出、导入的标识符是否真实存在、拼写是否准确。它直接拦截因变量名、函数名、属性名拼写错误引发的 ReferenceError 或 undefined is not a function 类型异常，把问题暴露在开发早期。
拼写错误为何容易逃过人工审查
人眼对相似字符串（如 appPrefix 与 appPreefix）、大小写混用（accountId vs accountID）、下划线/驼峰混淆（user_name vs userName）不敏感。这类错误不会阻碍代码编译或启动，但首次调用时立即崩溃，堆栈信息常指向使用处而非定义处，定位成本高。
模块系统如何实现静态校验
现代模块系统通过明确的“绑定声明”建立可验证的符号关系：
- ESM（
import/export）在解析阶段就检查导入名称是否匹配导出声明，不匹配直接报SyntaxError: The requested module does not provide an export named 'xxx' - TypeScript 在类型检查阶段验证所有导入标识符是否在对应模块的
export列表中，拼错即报红，且提示可用的正确名称 - Python 的
importlib.util.find_spec()或静态分析工具（如 mypy +--disallow-untyped-defs）可检测未声明的from x import y中y是否真实存在
对比无校验场景下的典型风险链
假设配置类导出 APP_PREFIX，但某处误写为 APP_PEEFIX：
- 无静态校验：程序正常启动 → 某个服务初始化时读取该值 → 得到
undefined→ 后续字符串拼接或对象访问触发TypeError→ 错误堆栈指向业务逻辑行，而非配置定义行 - 有静态校验：模块加载时报错，明确指出 “
APP_PEEFIXis not exported by ./config.ts”，错误位置精准，修复即时
它不是万能的，但堵住了最常见的一类漏洞
静态校验无法捕获运行时动态生成的键名（如 obj[configKey]），也不能替代输入校验或契约检查。但它对显式声明的模块边界——也就是开发者主动书写 import 和 export 的地方——提供了零成本、高确定性的防护。这种防护不依赖测试覆盖率，不依赖运行路径，只要模块被引用，校验就生效。
