函数声明提升非bug但易引发隐性问题，应通过const/let函数表达式、顶层声明、命名隔离及工具链约束来保障可预测性。
函数声明提升本身不是 bug，但容易引发调用时机错觉、同名覆盖、依赖未就绪等隐性问题。规避核心不靠“禁止提升”，而是通过声明方式选择、作用域控制和工程约束，让代码行为可预测、可调试、可协作。
优先用 const/let 声明函数表达式
函数表达式不会被完全提升，配合块级作用域变量能明确生命周期和可见范围，所有现代引擎行为一致：
- 用 const handleClick = () => { ... }; 替代 function handleClick() { ... }
- 避免 var 声明函数：var fn = function(){} 会把 fn 提升为 undefined，调用时报 TypeError
- let/const 声明的函数在声明前访问直接抛 ReferenceError，反而提前暴露问题
顶层定义 + 条件调用，而非块内声明
不要在 if、for 等语句块里写 function foo() {} —— 这不符合规范，Chrome/Firefox 严格模式下直接报 SyntaxError，IE 和 Safari 行为不一致：
- 把函数声明放在模块或函数顶层，用 if 控制是否执行：if (ready) init();
- 需要分支逻辑时，用函数表达式赋值：const handler = type === 'A' ? handleA : handleB;
- 多步骤初始化用 IIFE 封装：if (needPolyfill) { (function() { patchFetch(); })(); }
命名与作用域隔离防冲突
函数提升优先级高于变量提升，同名函数声明会被后续 var 赋值覆盖，导致静默故障：
- 避免函数名与配置对象、状态变量重名，例如不要同时有 function config() {} 和 const config = { api: '...' };
- 模块内统一用对象封装：const utils = { formatDate(), debounce() };
- 大型项目采用 ES 模块导出，天然隔离作用域：export const validateEmail = () => {...};
用工具链固化防御习惯
单靠记忆易疏漏，需把规则落地为开发流程中的硬性检查：
- 脚本顶部加 "use strict";，让非法声明在解析阶段就失败
- ESLint 启用 no-redeclare（禁止重复声明）、no-shadow（禁止遮蔽外层变量）、no-unused-vars
- CI 流程中 lint 失败即阻断合并，从源头过滤非标写法
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
