vscode本身不自带“代码生成速度提升十倍”能力，真正起效的是插件对重复结构、样板代码和上下文感知补全的自动化处理；关键在选对场景、配对参数、避开默认行为陷阱。
VSCode 本身不自带“代码生成速度提升十倍”的能力，真正起作用的是插件对重复结构、样板代码和上下文感知补全的自动化处理。单纯装插件不会提速，关键在于选对场景、配对参数、避开默认行为陷阱。
Tabnine 和 GitHub Copilot 的补全触发时机差异
两者都依赖光标位置和前缀文本触发，但实际响应逻辑不同：Tabnine 更倾向基于本地项目语料训练，对私有函数名、变量命名风格适应快；Copilot 则强依赖云端模型，对通用框架（如 React hooks、Spring Boot 模板）响应更稳，但离线时几乎不工作。
- 在
typescript文件中写use后按Tab，Copilot常推荐useState/useEffect，而Tabnine可能优先补全你项目里自定义的useApi或useAuth -
Copilot默认启用inline suggestions（内联建议），容易误触；可在设置里关闭，改用Ctrl+Enter手动唤出面板，减少干扰 -
Tabnine的tab键采纳是逐词级，Ctrl+.才是整行采纳，这点和多数人直觉相反，容易卡在“想按 Tab 却没反应”
toString() 一键生成插件的实际限制
Java 项目里所谓“一键生成 toString()”插件（如 Java Extension Pack 内置功能或 Generate All Setter/Getter/ToString 类插件），本质是调用 SourceAction API 调用 JDT LS（Java Language Server）。它不是魔法，受限于 AST 解析完整性。
- 如果类里有泛型嵌套过深（如
Map<string list>>></string>），部分插件会跳过字段或生成空字符串 - 字段含
transient或@JsonIgnore时，是否忽略取决于插件配置项java.configuration.updateBuildConfiguration是否启用 - 生成结果默认用
StringBuilder，不支持切换为String.format或 Lombok 风格，需手动替换
Glean 插件在 React 重构中的真实开销点
vscode-glean 的“提取组件”“状态重命名”等功能看似一键，但背后依赖完整的 AST 重写和 import/export 修复。它快的前提是：当前文件已被 TypeScript 编译器正确解析，且没有语法错误。
- JSX 中存在未闭合标签或非法表达式（如
{foo && <div>} 少了右括号），<code>Extract Component会直接失败，报错Unable to parse JSX content - 跨文件状态提取（比如把子组件里的
useState提到父组件）目前不支持，插件只做单文件 AST 操作 - 重命名
const [count, setCount] = useState(0)时，若setCount在别处被解构使用（如const { setCount } = props），插件不会识别该引用，导致漏改
真正影响“生成速度”的从来不是插件数量，而是你是否清楚每个插件的解析边界——它能读到什么、不能读到什么、在什么 AST 节点上生效。盲目依赖提示，反而比手写慢。
