单靠插件不能自动完成模块化，但能显著降低拆分成本、规避常见错误；关键在于选对插件并理解模块化本质——按职责边界隔离实现与接口，而非简单切分代码。
VSCode插件如何辅助C++/Python/JS函数模块化拆分
直接说结论：单靠插件不能自动完成模块化，但能显著降低拆分成本、规避常见错误。关键在于选对插件+理解模块化本质——不是“把代码切开”，而是“按职责边界隔离实现与接口”。
用Glean插件提取函数/组件时的参数陷阱
很多人以为选中一段代码右键 Extract Component 就完事了，结果生成的函数缺少必要参数或类型声明，导致编译失败或运行时 undefined。
- JS/TS 中，Glean 会尝试推断 props，但对闭包变量、上下文（
this）、异步回调里的依赖常漏判 - C++ 模块化场景下，它不处理头文件声明同步——你提取出一个
calculateTax()函数，Tax.h不会自动加声明，Tax.cpp也不会自动补实现 - Python 场景中，它默认不导出新函数到
__all__，也不更新from module import *的可见性
建议操作：提取后立刻检查三处——函数签名是否完整、调用方是否需手动补 import、对应语言的接口文件（.h / .pyi / index.ts）是否同步更新。
Prettier + ESLint 组合对模块化代码风格的实际影响
模块化后最易被忽略的是跨文件一致性。比如 utils/string.js 用 export default，而 utils/date.js 用命名导出，团队协作时 import 方式混乱，重构时极易出错。
真实影响点：
-
prettier.semi: false和eslint rule 'semi': ['error', 'never']必须严格一致，否则保存时反复格式化冲突 - ESLint 的
no-unused-vars在模块拆分初期会误报——刚拆出的函数还没被引用，插件会标红，但这是正常过渡态，别急着删 - 对 C++，Prettier 不生效，必须靠
clang-format配合；且.clang-format中的IncludeIsMainRegex要设为'^(.*[\/])?[^\/]+.h$$'，否则头文件和源文件格式不统一
为什么 Bracket Pair Colorizer 比想象中更重要
模块化开发中，函数嵌套层级加深（尤其在 React 组件或 C++ 模板元编程里），括号匹配错误是高频编译失败原因。不是语法问题，而是人眼误判。
典型现象：
- 复制粘贴一段逻辑进新函数时，少了一个
}，VSCode 默认高亮只显示最近一对，根本看不出缺在哪 - Python 的
def+if+for嵌套后，缩进正确但括号逻辑错位，Bracket Pair Colorizer用颜色强制暴露结构断裂点 - 配置项
bracket-pair-colorizer-2.highlightMatchingBracket必须开启，否则光标停在{上时，对应}不高亮，失去核心价值
真正卡住模块化进度的，往往不是设计问题，而是这种低级但难定位的结构错误——它让开发者反复怀疑“是不是接口写错了”，实际只是少了个括号。
