函数声明提升是编译期行为，优先级高于变量提升，使函数可提前调用但不保障内部依赖就绪；同名变量赋值会覆盖函数引用，需避免隐式冲突。
函数声明提升不是语法糖，而是一种编译期行为，它直接影响代码组织逻辑、协作预期和错误定位方式。理解它，不只是为了避开 undefined is not a function 这类报错，更是为了在架构层面做出更稳的决策。
让主流程“先见为快”
函数声明会被整个提升（声明+定义），所以你可以把核心调用写在文件顶部，再把具体实现放在后面——比如初始化入口、路由分发、数据加载这类关键路径，读代码时一眼就能抓住主线，不用来回滚动找定义。这特别适合团队协作或长期维护的项目：新成员打开文件，先看到 initApp()、setupRouter()、fetchData() 被调用，再往下才看到它们的实现，逻辑层级自然清晰。
- 避免把所有函数都塞在顶部，导致定义堆砌、重点模糊
- 不建议在提升后立即依赖尚未定义的变量（如函数内部用到的全局配置），因为变量提升只提声明，不提赋值
- 如果函数依赖外部模块或异步准备的数据，提升本身不能解决时序问题，仍需显式判断
区分“可提前调用”和“可提前依赖”
提升 ≠ 所有内容都就绪。函数能被提前调用，不代表它内部引用的变量或函数也已就绪。例如：
run(); // ✅ 可执行
function run() {
console.log(config.env); // ❌ config 还没赋值，输出 undefined
}
var config = { env: 'production' };
这里 run 被提升了，但 config 只是声明提升，赋值仍在原位。设计时要明确：提升提供的是“调用许可”，不是“运行保障”。关键依赖建议显式检查或封装成 lazy-init 模式。
警惕同名冲突与覆盖顺序
函数提升优先级高于变量提升。当函数声明和同名变量声明共存时，函数会先被提升，变量声明不会覆盖它；但后续的赋值会覆盖函数引用：
foo(); // 输出 "func"
var foo = 'hello';
function foo() { console.log('func'); }
foo(); // 报错：foo is not a function
这种隐式覆盖容易引发线上静默故障。设计上应避免同名混用，尤其在模块顶层或工具函数集合中。若需动态替换行为，用对象属性或 Map 管理更可控，而不是依赖提升顺序博弈。
- 命名函数尽量语义唯一，不与配置变量、状态对象重名
- 工具库导出函数时，优先用函数声明而非表达式，确保 API 名称稳定出现在堆栈中
- 构建阶段开启
no-unused-vars和no-shadow等 lint 规则，提前捕获潜在覆盖
在现代工程中理性取舍
ES6 后，箭头函数、let/const、模块化已成主流，函数提升的“便利性”在某些场景反而成了认知负担。比如：
- React 函数组件内不推荐用函数声明提升来调整渲染顺序，用
useEffect或条件逻辑更直观 - ESM 模块中，顶层
import必须在最前，函数提升无法绕过模块加载顺序 - 使用 TypeScript 时，类型检查器不依赖提升行为，过度依赖可能掩盖类型定义缺失问题
真正值得保留提升优势的，是那些需要跨作用域早期介入、且逻辑稳定的入口函数——比如 CLI 工具的命令分发器、Node.js 的 require 后钩子、或 SSR 渲染前的数据预取函数。其余场合，显式顺序更利于调试和重构。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
