能，但必须确认光标落在函数声明或调用位置——插件基于 TypeScript Language Server 的 AST 分析识别 const fn = function() {} 和 function fn() {}，支持 Convert to arrow function、Extract function 等转换，若原函数显式使用 this 则跳过并提示“unsafe”。
JavaScript Booster 能否安全重构函数？
能，但必须确认光标落在函数声明或调用位置——插件只在语义明确的上下文中触发重构选项。它不依赖正则硬匹配，而是基于 TypeScript Language Server 的 AST 分析，所以 const fn = function() {} 和 function fn() {} 都能识别，但 var fn = () => {} 这类混合写法可能漏掉灯泡提示。
常见错误现象：光标停在函数体内部（比如 return 行）时，弹出的是“Replace with template string”之类局部优化，而非函数级重构；此时需把光标移到函数名或 function 关键字上再点灯泡。
- 支持的转换包括：
Convert to arrow function、Extract function、Inline function - 箭头函数转换后自动处理
this绑定风险：若原函数显式使用this，插件会跳过转换并提示“unsafe” - 参数解构、默认值、剩余参数均保留，不破坏原有语义
Bracket Pair Colorization 如何提升函数嵌套可读性？
VSCode 内置的括号高亮（非旧版插件）对函数体边界识别更准，尤其在 JSX 或带多层条件的函数中，{}、[]、() 用不同颜色区分，避免误判闭合位置。
使用场景：写一个含 map + filter + 回调函数的链式调用时，光标停在最外层 ) 上，对应开头的 ( 会高亮同色，中间所有嵌套括号按层级配色，一眼看出哪段属于哪个函数作用域。
- 必须开启设置：
"editor.bracketPairColorization.enabled": true - 禁用
"editor.guides.bracketPairs": false，否则彩色高亮会被灰色引导线干扰 - 颜色池默认 6 种，深嵌套时建议加一条：
"workbench.colorCustomizations": {"editorBracketHighlight.foreground1": "#ff6b6b"}手动强化最内层
如何用装饰器标记函数调用链？
这不是开箱即用功能，需配合插件如 vscode-jest 或自定义装饰器逻辑——核心是通过 TextEditorDecorationType 在函数调用处打标记，而非修改源码。
例如，在 React 组件中点击 useEffect，想高亮所有被它调用的自定义 Hook（如 useApi），就得先解析 AST 找到调用关系，再用 setDecorations() 给目标行加背景色或边框。
- 性能关键：必须加防抖（debounce）和缓存，否则每次光标移动都触发 AST 解析会卡顿
- 推荐轻量方案：用
eslint-plugin-react-hooks规则配合ESLint插件的“Quick Fix”提示，比纯视觉标记更可靠 - 不要依赖正则匹配函数名，
handleClick可能是事件处理器也可能是普通工具函数，需结合调用上下文判断
Prettier + ESLint 对函数格式的影响
它们不改变函数逻辑，但强制统一缩进、换行、空格位置，间接提升可读性。比如 prettier 会把长参数列表折成多行，eslint 的 max-params 规则则直接报错提醒你拆分函数。
容易踩的坑：prettier 默认不处理函数注释对齐，而 jsdoc 插件要求 /** */ 块注释中每行 * 对齐——两者冲突时，保存后注释可能错位。
- 解决方案：在
.prettierrc中加"jsdocSpaces": 1（需 prettier v3.0+） -
eslint规则func-names设为"as-needed"，避免强制命名匿名函数破坏箭头函数简洁性 - 函数体单行返回（
=> expr）和多行（=> { ... }）风格由prettier自动判断，无需手动干预
函数可读性的最大陷阱不在工具配置，而在忽略作用域和副作用。哪怕所有括号都高亮、所有函数都转成箭头、所有注释都格式整齐，如果一个函数既发请求又改 state 还操作 DOM，再好的插件也救不了可读性。
