从用别人代码到贡献代码
刚入行那会儿，我也只会搜 GitHub 上的轮子直接拿来用。直到有次线上出问题，发现某个依赖库有个小 bug，等官方修复得等到猴年马月。一咬牙，自己改了代码提交了 Pull Request，没想到还真被合并了。那一刻突然觉得，原来我也可以是那个写轮子的人。
先别急着写代码
很多人以为参与开源就得立刻上手改核心逻辑，其实最缺的反而是文档、示例和测试。你可以先挑一个常用的项目，跑一遍 demo，把不清楚的地方补进 README。比如你发现某个配置项没写清楚，导致你折腾了两小时，那就把它写明白，提个文档 PR，维护者通常很欢迎这种贡献。
找对项目下手
别一上来就冲 Kubernetes 这种巨无霸。去 GitHub 搜索标签 good first issue，筛选语言和领域，找那些活跃但不算太卷的项目。我第一个正式贡献是在一个轻量级 CLI 工具上，作者回复特别快，还耐心指导我调整格式，体验感拉满。
学会提高质量的 Issue
有时候不写代码也能帮大忙。遇到问题别只说“跑不起来”，要像写 Bug 报告一样：环境版本、复现步骤、错误日志都列清楚。有的项目维护者看到这种细致的反馈，会主动邀请你一起排查，自然就进入协作节奏了。
PR 要小而准
别一口气重构整个模块。一次 PR 只解决一个问题，比如修复拼写、增加日志、优化一处边界判断。附上简单的测试说明，让 reviewer 快速理解你的意图。下面是个典型的 commit message 写法：
fix: 修复用户登出后 token 清除不彻底的问题
当用户点击登出时，localStorage 中的 refreshToken 未被删除，
导致重新登录时可能复用旧 token。本次修改在 logout 方法中
显式清除 refreshToken，确保状态干净。
Closes #123别怕被拒
我第二个 PR 就被拒了，理由是实现方式不符合项目设计哲学。当时有点沮丧，但作者给出了替代方案，后来按建议重做才合入。开源社区看重长期协作，一次拒绝不代表终结，反而可能是深入交流的开始。
把开源变成习惯
现在我每周花两三小时逛一下关注的项目。修个小错、回个 issue、更新下依赖，慢慢就成了日常。有次公司项目要用的新特性，刚好我在另一个开源库见过类似实现，顺手借鉴还反哺了原项目。这种双向流动的感觉，比单纯搬砖有意思多了。