setTimeout传字符串回调存在执行不可控、作用域混乱、XSS风险、内存泄漏及Node.js不兼容五大隐患，应始终改用函数形式。
setTimeout 传字符串当回调，看着省事，实际埋了多个隐患——执行不可控、作用域混乱、XSS 可利用、内存难回收，还可能在 Node.js 环境直接报错。
字符串参数会隐式调用 eval
当你写 setTimeout('console.log("hi")', 100)，JavaScript 引擎内部会把它当作 new Function('console.log("hi")') 来构造并执行。这等价于动态执行任意代码，和直接用 eval() 一样危险。
- 所有输入若来自用户（比如 URL 查询参数、表单提交、localStorage 数据），攻击者就能注入恶意脚本
- 即使内容看似“静态”，一旦后续拼接变量（如 'alert(' + userInput + ')'），风险立刻放大
- 现代浏览器虽做了一定限制，但全局作用域执行逻辑仍在，无法彻底规避漏洞面
作用域行为反直觉，容易引发 Bug
字符串形式的回调总是在全局作用域中执行，无法访问外层函数的局部变量，也不受闭包保护。
- 写 setTimeout('console.log(a)', 100)，其中 a 只能是全局变量或 window 上的属性
- 若误以为它能读取当前函数内的 let a = 42，运行时就会报 ReferenceError
- 调试时很难追踪：控制台报错行号指向“动态生成的函数”，没有源码映射
存在潜在内存泄漏风险
每次传字符串，引擎都要新建一个 Function 实例。这些实例可能意外捕获全局对象、DOM 节点或大对象引用，且不易被垃圾回收器识别。
立即学习“Java免费学习笔记（深入）”；
- 尤其在循环或高频定时任务中反复使用字符串参数，会持续创建不可回收的函数对象
- 某些旧版浏览器或特定运行环境里，这类函数还会延长其引用链生命周期
- 相比直接传函数字面量（() => {...}），字符串方式缺乏明确的作用域边界，排查更困难
Node.js 环境直接不支持
Node.js 从较早版本起就禁止 setTimeout 第一个参数为字符串，调用会立即抛出 TypeError。
- 例如：setTimeout('process.exit()', 100) 在 Node 中运行失败，而浏览器却可能“侥幸”通过
- 这种环境差异会导致代码跨平台不可靠，增加测试和维护成本
- 团队协作中，新人容易忽略该限制，写出本地能跑、上线即崩的代码
安全写法很简单：始终用函数代替字符串。比如把 setTimeout('doWork()', 500) 改成 setTimeout(doWork, 500) 或 setTimeout(() => doWork(), 500)。既清晰又可控，还能让工具链（如 ESLint）有效检测问题。
