• 按下Cmd+Shift+P（macOS）或Ctrl+Shift+P（Windows/Linux），调出命令面板。
• 输入Flutter: Change SDK Path并选中。
• 在弹出的输入框里，直接填入Flutter SDK的绝对路径，例如/Users/you/development/flutter或C:\src\flutter。
• 回车确认后，留意VS Code右下角，应该会弹出Dart SDK loaded的提示，这才算生效。
• 顺手检查一下设置：这个操作通常会自动在用户设置里写入dart.flutterSdkPath项，可以避免下次重装插件后路径再次丢失。

插件装了但调试按钮灰色 / 点击报 “No debug adapter found for flutter”

这是另一个典型问题：项目能正常打开，代码也有语法高亮，pubspec.yaml文件也能被正确解析，但就是那个绿色的运行（▶️）按钮是灰色的，或者点击后弹窗提示“找不到Flutter的调试适配器”。

这种情况，基本可以锁定是flutter命令链断裂了。要知道，VS Code的Flutter插件在后台会调用flutter daemon这个命令来维持设备监听和热重载的通信通道。一旦这个底层命令启动失败，整个调试流程就会卡死。

• 先做基础诊断：打开VS Code的内置终端，直接运行flutter daemon命令，看看是否报错。常见的错误有command not found（命令找不到）、Permission denied（权限被拒绝），或者卡在“Waiting for another flutter command...”这样的提示上。
• Windows用户注意：环境变量PATH一定要添加到“系统变量”里。如果只加在“用户变量”中，从图形界面启动的VS Code很可能读取不到。
• macOS用户的验证方法：如果你从终端用code --new-window命令启动VS Code，flutter daemon大概率能跑通；而直接从Dock启动则可能失败。这本身就说明了问题所在。
• 关注flutter doctor的细节：运行flutter doctor -v时，别忽略输出末尾的信息。它最后其实也在尝试调用flutter daemon，如果这里挂了，插件瘫痪就是必然结果。

装完插件后仍看不到设备列表

状态栏一直显示No Device或者设备列表为空？这不一定代表插件没起作用，更可能是“设备发现”这个环节出了问题。需要明确一点：Flutter插件本身并不管理设备，它只是把flutter devices这个命令的输出结果，友好地展示在状态栏里而已。

所以，排查的第一步永远是：在VS Code的终端里，手动执行一次flutter devices。

• 如果命令输出为空或者直接报错，那说明是Android或iOS的工具链没配置好（比如Android许可证未接受、Xcode命令行工具缺失）。这是环境问题，和插件本身无关。
• 如果flutter devices能正常列出设备，但VS Code状态栏还是空的，可以尝试点Cmd/Ctrl+Shift+P，输入Flutter: Refresh Devices命令，强制刷新一次设备列表。
• Android真机用户：请确认手机的USB调试模式已打开，并且在电脑上执行adb devices后，设备状态显示为device（而不是unauthorized）。
• iOS模拟器用户：必须确保模拟器至少通过Xcode启动过一次。否则，底层的xcrun simctl list devices命令可能无法返回可用的设备信息。

说到底，环境变量和命令行工具链才是整个开发环境的“地基”，插件只是站在这个地基上的“施工队”。很多问题表面上看起来是插件“不工作”，实际上却是flutter命令在某个环节静默失败了。因此，遇到问题时，仔细审视flutter doctor -v的每一行输出，往往比反复重装插件要管用得多。