函数声明提升不是漏洞但会放大编码疏忽，导致依赖未就绪、同名覆盖、块级污染及原型篡改等风险；应加存在性判断、用const声明、块内用表达式、启用严格模式并冻结原型。
函数声明提升本身不是漏洞，但它会放大编码疏忽，让看似合理的写法在运行时突然失效——尤其是当开发者误以为“能调用=已就绪”时。
函数能提前调用，不等于内部依赖已加载
函数声明被完全提升，意味着 函数名和函数体都可立即使用；但函数内部引用的变量、配置或模块，只提升声明，不提升赋值。如果没做显式检查，就容易读到 undefined 或触发静默错误。
- 比如
initApp()放在顶部调用，但它依赖的API_BASE_URL是后面才赋值的 var 变量 → 函数执行时拿到的是 undefined - 解决办法：关键依赖加存在性判断，或改用 lazy-init 模式（如
getApiUrl = () => API_BASE_URL || fallback） - 更稳妥的做法是把初始化逻辑封装成函数，明确其执行时机，而不是依赖提升顺序
同名覆盖导致行为被悄悄替换
函数提升优先级高于 var 变量提升。当同名的函数声明和 var 声明共存时，函数先被提升；但后续的 var 赋值会直接覆盖函数引用——这不会报错，却让第二次调用直接崩溃。
- 典型场景：
run(); function run(){...} var run = 'done'; run();→ 第二次调用报TypeError: run is not a function - 这种覆盖在模块顶层或工具函数集合中尤其危险，可能影响整个流程链
- 规避方式：禁止同名混用；导出函数统一用 const 声明（
const run = () => {...}），从源头切断覆盖可能
块级作用域内函数声明的非标准行为
在非严格模式下，块级作用域（如 if、for 内）里的函数声明会提升到外层作用域，造成意料之外的作用域污染和覆盖。
- 例如在 if 块里写
function handler() { ... }，结果全局或外层函数里也多了一个handler - 不同浏览器实现曾不一致，ES6 后虽规范为“块级函数声明”，但旧环境仍存在兼容风险
- 推荐写法：块内一律用函数表达式（
const handler = () => {...}）或箭头函数，避免声明提升带来的不确定性
沙箱环境下的原型篡改跳板
函数提升本身不可禁用，但攻击者可利用它配合非严格模式下的 this 指向，动态重写内置原型方法，绕过沙箱限制。
- 例如在未启用严格模式的脚本中，提升后的函数内
this指向 globalThis，进而可修改Array.prototype.push - 防御重点不在阻止提升，而在切断篡改路径：早期冻结
Object.prototype、Array.prototype；全局启用"use strict"；禁用eval和Function构造器 - 对敏感 API（如
setTimeout、JSON.parse）做代理封装，不暴露原始接口
