应向对应扩展仓库提交 issue，而非 vscode 主库；需明确问题归属、提供完整复现步骤、环境信息、日志截图及纯净环境验证。
直接去对应仓库提交 issue，别发到 VSCode 官方主库（除非是编辑器本体问题），也别只在社区帖子里喊话——90% 的反馈卡在没进对地方。
确认问题归属：VSCode 本体 vs 扩展
插件出问题，比如 vscode-leetcode 提交失败、Python 扩展无法跳转定义，必须去该扩展的 GitHub 仓库，不是 microsoft/vscode。点开 VSCode 扩展面板 → 找到对应扩展 → 点“Report Issue”，它会自动跳转到正确地址。误提交到主库会被快速关闭，且不通知你。
- VSCode 本身崩溃、设置不生效、终端异常等 → 提交到
https://github.com/microsoft/vscode/issues - 某个扩展功能缺失或报错 → 查扩展详情页的 “Repository” 链接，或在扩展页面点 “Report Issue”
- 不确定？看错误日志里是否出现扩展名，比如
[Python] Unable to import 'requests'就属于 Python 扩展范畴
一份有效 Bug 报告必须含这 5 项
开发者不会猜你做了什么。缺任何一项，大概率被要求补全，拖慢修复进度。
-
OS：写具体版本，如macOS Sonoma 14.5，不是“Mac” -
VS Code版本：帮助 → 关于 → 复制完整字符串，如1.87.2 (Universal) - 扩展名与版本：
vscode-leetcode v0.22.0，不是“LeetCode 插件” - 复现步骤：按顺序编号，例如“1. 打开题目 206；2. 粘贴代码；3. 点击 Submit；4. 控制台报
TypeError: Cannot read property 'test' of undefined” - 预期行为 vs 实际行为：明确写清，比如“应显示 AC 状态，实际弹出空白弹窗并控制台报错”
功能建议要绑定具体场景，别只说“希望更好”
空泛需求（如“增加暗色主题支持”）几乎不会被采纳。VSCode 团队和扩展维护者优先处理能被量化、有明确用户路径的改进。
- 描述你在哪一步卡住了：例如“在
vscode-leetcode中调试时，每次都要手动切到 Debug 视图再设断点，无法在题目编辑器内右键‘Add Breakpoint’” - 说明当前 workaround 多麻烦：比如“必须先保存为 .ts 文件 → 手动打开该文件 → 再调试，打断题解流程”
- 给出可落地的方案：如“在题目编辑器右键菜单中加入
Add Breakpoint选项，复用 TypeScript 调试逻辑” - 附上已有类似实现参考：比如“
Python扩展在 .py 文件编辑器中已支持此操作”
别忽略日志和截图这些“证据型”信息
很多问题靠文字描述根本无法复现，尤其涉及 UI 渲染、异步状态或权限异常。开发者第一反应就是看日志，而不是读你的文字推演。
- 打开 VSCode 开发者工具：
Help → Toggle Developer Tools，切换到 Console 标签页，复现问题后复制全部红色错误行 - 输出面板（
Ctrl+Shift+U）里找对应扩展的通道，比如LeetCode或ESLint，截取相关日志 - 录屏比静态截图更有力：用系统自带工具录下从打开文件到触发问题的全过程，重点展示鼠标位置、焦点状态、弹窗顺序
- 避免上传模糊截图或只截代码不截上下文 —— 错误堆栈不完整、路径被遮挡、控制台折叠都等于没提供
最常被忽略的是复现环境的纯净性：很多人没关其他扩展就提交 bug，结果发现是扩展冲突。建议先用 code --disable-extensions 启动 VSCode，再测试一次 —— 这个动作花不了 10 秒，但能帮你省下一半来回沟通时间。
