Ctrl+. 是触发快速修复的唯一可靠快捷键，必须作用于语言服务器识别的可修复诊断 token 上；失效主因是文件语言未识别、语言服务器缺失、诊断非语义层或光标位置错误。
Ctrl+. 是触发快速修复的唯一可靠快捷键，不是点按、不是右键菜单默认项、也不依赖鼠标悬停灯泡——它必须作用于被语言服务器识别为“可修复诊断项”的 token 上。
为什么 Ctrl+. 按下后没反应或弹出空白菜单
这不是快捷键失效，而是 VSCode 没拿到可操作的修复建议。常见原因包括：
- 文件未被识别为对应语言：右下角状态栏显示
Plain Text或JSON，而非JavaScript、TypeScript、C++等；点击它手动切换语言模式 - 缺少必要语言服务器：例如 C++ 项目没装
C/C++插件，Python 文件没启用Pylance，此时Ctrl+.无响应是正常表现 - 错误来自编译器（如
g++报错）而非语言服务：VSCode 默认不把终端编译输出转为可修复诊断，需配合ms-vscode.cpptools的errorSquiggles配置或 ESLint 类插件桥接 - 光标位置不对：必须落在报错标识符内部（比如
std::thread中任意字符），不能只在行首或空格处
C++ 编译告警（如 thread 构造失败）怎么进 Quick Fix
C++ 的 Quick Fix 能力高度依赖 ms-vscode.cpptools 插件是否启用了语义诊断。对 std::thread 参数不匹配这类问题，仅靠语法高亮无法触发修复，需满足：
- 项目根目录存在
c_cpp_properties.json，且"intelliSenseMode"设置为gcc-x64或clang-x64，而非msvc-x64 -
"cppStandard"明确设为"c++17"或更高（不能只靠编译命令里的-std=c++11） - 确保
compile_commands.json已生成并被插件加载（尤其在使用 CMake 的项目中） - 部分告警（如
unused variable）默认不进 Quick Fix，需在设置中开启："C_Cpp.errorSquiggles": "Enabled"并配合"C_Cpp.enhancedColorization": true
满足上述后，Ctrl+. 才可能给出 “Add missing #include <thread>” 或 “Use C++17 standard” 类建议。
保存时自动修复编译风格类告警（ESLint/Prettier）
编译告警本身不会被自动修复，但由 ESLint、Prettier 等工具报告的格式/风格类问题可以。关键配置在 settings.json 中：
- 启用保存即修：
"editor.codeActionsOnSave": { "source.fixAll.eslint": true } - 若用 Prettier 做最终格式化，加：
"source.fixAll.prettier": true（需已安装esbenp.vscode-eslint和esbenp.prettier-vscode） - 注意冲突：ESLint 和 Prettier 规则重叠时，
prettier会覆盖eslint的格式建议，但类型检查、未使用变量等仍走 ESLint - 对 C++，
cpptools不支持codeActionsOnSave自动修，只能手动Ctrl+.或配置外部格式化器（如clang-format）
真正卡住人的从来不是“怎么修”，而是“为什么这个红波浪线根本不给我修的选项”——它背后是语言模式、插件状态、诊断来源、token 定位四层嵌套判断。每次 Ctrl+. 失效，先看右下角语言名，再开开发者工具查 Console 里有没有 LanguageClient 启动失败日志，比反复重装插件快得多。
