灯泡提示（Quick Fix）需满足语言服务器就绪、光标置于波浪线标识符上、文件被正确识别为对应语言、editor.quickSuggestions启用等条件；否则不出现或选项缺失。
灯泡提示（Quick Fix）不是装饰，它是你代码出问题时第一个该看的地方——只要光标停在带波浪线的行上，按 Cmd + .（macOS）或 Ctrl + .（Windows/Linux），就能直接看到修复选项。
为什么灯泡不出现？常见触发失败原因
灯泡图标没弹出来，通常不是功能坏了，而是条件没满足：
- 语言服务器没启动：比如打开一个
.js文件但没装JavaScript and TypeScript Nightly扩展，或 Python 文件没选对解释器，diagnostics就不会上报问题，自然没灯泡 - 光标没落在“问题区域”：波浪线可能跨多词（如
consloe.log），但灯泡只在你把光标放在consloe上才稳定出现；放在.log后面就可能失效 - 设置关了悬停提示：检查
"editor.quickSuggestions"是否为true，尤其是"other"子项被设为false时，灯泡会变迟钝 - 文件没被识别为对应语言：后缀是
.txt或没后缀，VSCode 默认用 Plain Text 模式，不跑任何语言服务——右下角点击语言模式手动切到JavaScript或TypeScript
Cmd + . 弹出来的菜单里没有想要的选项？
不是所有修复都默认启用。比如想让 source.organizeImports 出现在菜单里，得先确保它被允许触发：
- 检查
settings.json中是否禁用了相关操作："editor.codeActionsOnSave"本身不影响Cmd + .菜单，但"javascript.suggest.autoImports"或"typescript.preferences.includePackageJsonAutoImports"关了，就看不到自动导入建议 - 某些操作只在特定上下文中激活：比如“提取为函数”必须选中一段可执行语句（不能只选个字符串字面量），且当前语言扩展支持该重构（Pylance 支持 Python 提取，但原生 JS 支持更全）
- ESLint 规则没配好：如果想看到
eslint: fix 'no-console'这类选项，得确认项目有.eslintrc.cjs，且 ESLint 扩展已启用、没报错
保存时自动修复和手动触发的区别在哪？
两者底层调用的是同一套 CodeAction 提供者，但触发时机和默认行为不同：
-
editor.codeActionsOnSave配置的是“静默执行”：比如设"source.fixAll": true，保存时直接改代码，不弹窗、不预览；而Cmd + .是交互式选择，能看到每个选项具体改什么 - 自动修复只做“安全操作”：像补
import、删未用变量这类低风险动作才会默认启用；重命名、提取函数等需用户确认的操作，不会进onSave流程 - 冲突优先级：如果同时开了
editor.formatOnSave和source.fixAll.prettier，格式化可能覆盖修复结果——推荐关掉formatOnSave，只留codeActionsOnSave统一控制
右键菜单里的“Refactor…”和灯泡里的“Quick Fix”有什么区别？
这是 VSCode 对两类操作的明确分离：
- 灯泡里的 Quick Fix 解决“诊断问题”：比如类型错误、拼写警告、缺失 import——它们来自
Diagnostic报告，属于“代码有问题，得修” - 右键 → Refactor… 做的是“主动优化”：比如提取函数、重命名符号、内联变量——不依赖波浪线，哪怕代码完全合法也能用，属于“代码能跑，但可以更好”
- 快捷键也不同：重命名用
F2，提取常量/函数常用右键或Cmd + Shift + P搜 “Extract”，而Cmd + .只管修复类动作
灯泡提示真正难搞的点不在怎么开，而在它“什么时候不该信”——比如 TypeScript 推导出的类型建议有时过于宽泛，ESLint 自动加的 await 可能破坏同步逻辑。别让它代替你思考，先看清楚它打算改哪几行、改完是否真符合语义，再按回车。
