JavaScript函数声明在模块中的行为表现

JavaScript 模块中的函数声明：作用域隔离超出你的预期

在 JavaScript 模块体系下，函数声明默认仅在当前文件范围内生效。若需跨模块共享，必须通过 export 导出、import 导入这一标准流程。未经导出的函数，其他模块无法访问，甚至在构建打包阶段，tree-shaking 机制也可能将其自动移除——这并非缺陷，而是模块系统的核心设计理念：天然隔离、按需暴露。

未导出的函数声明默认不对外可见

即便你在模块顶部书写了 function utils() { }，只要未添加 export，该函数就会被牢牢封装在当前模块作用域之内。其他模块无论采用何种方式 import，都无法获取它——这并非限制，而是设计原则：天然隔离、按需暴露。

• 未执行导出的函数，在构建阶段可能被 tree-shaking 自动剔除，从而有效缩减打包体积
• 使用 import * as mod from './x.js' 同样无法获取未导出的函数
• 调试时不可见、类型系统无法推导、IDE 也无法提供补全提示

导出语法决定了外部模块如何使用

若要将函数声明共享给其他模块，必须选择合适的导出语法，否则导入方可能遭遇报错或解构失败：

• 命名导出：export function formatTime() { } → 导入时必须使用 import { formatTime } from './x.js'
• 默认导出：export default function initApp() { } → 导入时可自由命名，例如 import start from './x.js'
• 先声明再导出：function helper() { } + export { helper }，适用于需要复用或条件导出的场景

块级作用域内无法声明并导出函数

像 if (true) { export function foo() { } } 这样的写法属于语法错误。export 必须位于模块顶层作用域，不能嵌套在条件语句、循环或函数内部。

• 函数声明本身可以被提升，但 export 是静态解析机制，不支持动态逻辑
• 若需按条件提供不同函数，建议改用导出对象或工厂函数，例如 export const api = isProd ? prodApi : devApi
• 浏览器和打包工具会直接抛出错误，切勿依赖非标准行为

模块加载顺序直接影响函数的可用时机

函数声明在当前模块内会被提升，但其“可用性”取决于整个模块是否已执行完毕。如果 A 模块导入了 B 模块，那么 B 中的函数声明一定先于 A 中的任何调用生效。

• 避免在模块顶层直接调用依赖其他模块状态函数（例如 initConfig()），以防执行顺序错乱
• 推荐将初始化逻辑封装为导出函数，由调用方按需触发，而非依赖模块加载时自动执行
• 异步加载（import()）会打破同步执行链，此时函数定义可能尚未就绪