为 VSCode 贡献代码需先跑通环境、再改小问题、最后提 PR；从 good first issue 入手，创建功能分支，补全测试，规范提交并响应反馈。
为 VSCode 贡献代码并不需要你已经是资深开发者，但需要理解它的开发流程、代码结构和社区规范。核心是：先跑起来、再改一点、最后提 PR。
熟悉项目与环境准备
VSCode 是用 TypeScript 编写的桌面应用，主仓库在 github.com/microsoft/vscode。官方文档有详细指引（github.com/microsoft/vscode/wiki/How-to-Contribute），务必先通读。
- 克隆仓库后，运行
yarn安装依赖，再执行npm run watch启动编译监听 - 用
npm run web或npm run electron启动 Web 版或桌面版，验证本地环境是否正常 - 推荐安装官方插件 “VS Code Extension Samples” 和 “TypeScript Debugger”，方便调试扩展逻辑
从 Issue 入手，找适合的初学者任务
GitHub 的 Issues 页面有带 good first issue 和 help wanted 标签的问题，通常是文档补全、小 Bug 修复或测试覆盖增强。
- 优先选 “test” 或 “docs” 类型的 issue，不涉及核心逻辑，反馈快、合入门槛低
- 评论该 issue 表明你打算处理（避免重复劳动），等待维护者确认或分配
- 不要直接 fork + 修改 main 分支 —— 创建独立功能分支，例如
fix-hover-tooltip-delay
编写、测试与提交代码
VSCode 对代码质量要求高，所有提交必须通过 CI 检查（包括 TypeScript 编译、单元测试、E2E 测试）。本地测试不能跳过。
- 修改前先运行
npm test确保原有测试通过；新增功能需补充对应单元测试（通常在src/vs/**/test/下） - 使用 VSCode 自带的 “Developer: Toggle Developer Tools” 查看控制台错误，配合断点调试
src/vs/workbench/等模块 - 提交信息按规范写：首行简短描述（50 字内），空一行后写正文说明改动原因和影响，结尾加
Fix #12345关联 issue
发起 Pull Request 并响应反馈
PR 是协作起点，不是终点。微软团队响应及时，但会严格审查代码风格、边界情况和测试完整性。
- 标题格式建议：
fix(terminal): prevent crash on resize with empty buffer - 描述里写清楚复现步骤、预期行为、实际行为，附截图或 GIF 更佳（尤其 UI 变更）
- 如果 CI 失败，点进详情看具体报错（比如 lint 错误、测试超时），本地修复后再 push —— 不要关闭重开 PR
- 维护者提出修改意见后，直接在原分支 commit 并 push，GitHub 会自动更新 PR
基本上就这些。真正卡住的往往不是技术，而是没看 Wiki、没跑通本地构建、或者跳过测试直接提 PR。耐心走完一遍，下一次就会顺很多。
