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()）会打破同步执行链，此时函数定义可能尚未就绪
