LeetCode 题解仓库贡献指南：从文件命名到 PR 合并的完整实操规范

LeetCode 题解仓库贡献指南：从文件命名到 PR 合并的完整实操规范

【免费下载链接】leetcodeLeetcode solutions项目地址: https://gitcode.com/GitHub_Trending/leetcode1/leetcode

本篇指南以仓库根目录的 CONTRIBUTING.md 为核心，系统讲解向本仓库提交 LeetCode 题解 PR 的完整规范：包括目录与文件命名约定、PR 标题与模板要求、多种解法组织方式，以及如何判断"是否值得提交"。读完你可以直接照着规范提交一份高质量、易评审、可合并的题解贡献。

仓库背景与贡献定位

本仓库托管的是 NeetCode.io 上展示的 LeetCode 题解（含 NeetCode 频道视频中演示的解法），站点的解法列表会周期性从该仓库同步更新。README 开头即说明了这一点，并在 README.md 的 Contributing 一节要求所有贡献者先阅读本指南再开 PR。

从仓库结构可以确认，解决方案按语言目录组织：c/、cpp/、csharp/、dart/、go/、java/、javascript/、kotlin/、python/、ruby/、rust/、scala/、swift/、typescript/，另有articles/（题解文章）与hints/（提示）。这些目录名本身就是贡献规范的一部分——新解法必须落入对应语言目录。

支持的贡献语言

指南明确：以下语言的解法会被 NeetCode.io 站点直接引用并建立链接：

• Python
• C++
• Java
• Javascript

同时，LeetCode.com 上"受支持的"其他语言解法同样欢迎提交（站点链接的语言范围在 README.md 中进一步扩展为 Python、Java、JavaScript、C++、Go、Swift、C#、TypeScript、Rust、Kotlin、Ruby、C、Scala 和 Dart）。也就是说，仓库鼓励多语言覆盖，但四个核心语言是站点优先引用的对象。

文件命名规范：必须严格遵守

贡献规范的第一条也是最重要的一条是匹配文件与目录的大小写风格，具体格式为：

<language>/<problem-number>-name-of-problem.<language-extension>

以仓库现有文件为实例对照：

例如 Java 版 Two Sum 的路径就是 java/0001-two-sum.java。题目名称可以直接从 LeetCode 题目页 URL 中获取，例如https://leetcode.com/problems/two-sum/的two-sum部分。

大小写问题

从仓库实际文件看，历史提交中存在大小写不完全统一的情况（如 c/1299-Replace-Elements-With-Greatest-Element-On-Right-Side.c 与 cpp/1299-Replace-Elements-with-Greatest-Element-on-Right-Side.cpp 风格各异），但贡献指南明确要求匹配现有文件与目录的大小写风格，因此新贡献者应以同语言目录下已有文件的命名风格为准，保持一致性。

PR 提交流程

贡献的基本流程是：

1. Fork 本仓库；
2. 从 README.md 的 Missing Solutions 表格中挑选一个尚缺解法的题目；
3. 用受支持的语言写出解法文件；
4. 开一个 PR 提交该缺失解法；
5. 如果你希望获得仓库的 collaborator 权限（可自行合并自己的 PR 或评审他人 PR），可以在 PR 中与维护者沟通说明。

PR 标题

指南要求给 PR 一个简洁且准确的标题，推荐格式为：

Create: 0001-two-sum.py

即Create: <按命名规范生成的文件名>。这样评审者扫一眼标题就能知道这个 PR 新增了什么语言的哪道题。

PR 模板

开 PR 时应遵循仓库的 PR 模板 .github/pull_request_template.md，模板要求填写三个关键信息：

• File(s) Modified：如0001-two-sum.py, 0002-add-two-numbers.py, etc...
• Language(s) Used：如python, javascript, etc...
• Submission URL：形如https://leetcode.com/problems/[problem-name]/submissions/xxxxxxxxx/

模板还提示了获取 Submission URL 的方法：在 LeetCode 的 Submissions 标签页中找到被标记为 Accepted 的那次提交，复制浏览器地址栏中的链接。模板特别提醒：合并前请确认文件名是小写，且同语言下不存在重复文件。

单一变更原则

指南建议一个 PR 只包含一个解决方案/一处变更。这不是硬性规则，但通常能显著缩短评审周期——评审者可以快速定位、快速验证，也便于在出问题时单独回退。

代码质量要求

贡献规范对解法代码本身提出了明确的质量标准：

• 能在 LeetCode 上通过提交：你贡献的代码必须能在 leetcode.com 上对应当前题目成功通过评测；
• 语义化命名：变量和方法名应具备语义，能够表达其含义；指南明确举例——单个字母的命名大概率不算是语义化的名称；
• 风格一致、易于理解：代码风格要统一，逻辑要清晰易读。

这一定位也与仓库的用途一致：这些解法会被 NeetCode 站点与视频直接引用，面向的是面试场景中的学习者，可读性比微小的性能优化更重要（详见下文 FAQ）。

常见问题（FAQ）详解

Q1：我的解法应该包含什么？

A：可以完全保持与你在 LeetCode 提交的解法一致，不需要编写测试用例，也不需要自己实现 LeetCode 内置的数据结构（如链表节点、二叉树节点、ListNode、TreeNode等）。

这一条直接决定了仓库文件的形态。以 java/0001-two-sum.java 为例，文件只包含一个Solution类与twoSum方法，没有main函数、没有测试代码；再如 python/0217-contains-duplicate.py，同样只有Solution类与核心方法。而 kotlin/0049-group-anagrams.kt 这类文件则附带了main函数用于本地验证——两种形态都在仓库中并存，但提交的最小单位是纯解法本身。

Q2：一道题有多种解法怎么办？

A：同一道题允许存在多个解法，前提是它们在思路或时间/空间复杂度上有实质区别。但有两条附加约定：

1. 首个解法必须与 NeetCode 频道上演示的算法保持一致——仓库的核心定位是同步站点与视频解法；
2. 多个解法应放在同一个文件里，并用语义清晰且可区分的命名，例如isValidBstIterative与isValidBstRecursive（迭代版与递归版）。

换句话说，不要为同一思路的微调版本单独开文件，而是用不同的方法名组织在同一文件中。

Q3：我的解法运行时间更低，但时间/空间复杂度相同，会被接受吗？

A：LeetCode 的运行时测量可能严重不准确，它随服务器负载、一天中的时段以及其他因素波动很大。因此：

• 在面试语境下，可读性与清晰度是比性能收益更重要的特性；
• 但那些透明地改进性能的变更也会被接受。

这条 FAQ 给出了清晰的取舍原则：不要为了几毫秒的运行时差异牺牲代码可读性，真正的性能提升（如复杂度优化）依然受欢迎。

Q4：我想加的题不在 NeetCode 150 列表或 Missing Solutions 表格中怎么办？

A：NeetCode 150 列表之外的题目也可以添加，但请优先补全列表内已有的缺失解法。

结合 README.md 的 Missing Solutions 表格可以理解这一策略：表格按 Arrays & Hashing、Two Pointers、Sliding Window、Stack、Binary Search、Linked List、Trees、Tries、Heap / Priority Queue、Backtracking、Graphs、Advanced Graphs、1-D/2-D Dynamic Programming、Greedy、Intervals、Math & Geometry、Bit Manipulation 等主题分类，并逐题列出 C、C++、C#、Dart、GO、Java、JS、Kotlin、Python、Ruby、Rust、Scala、Swift、TS 各语言的完成状态（✔️ 表示已有解法，❌ 表示缺失）。优先提交这些带 ❌ 的缺口，对站点的完整度贡献最大。

自动化与仓库维护机制

贡献规范之外，仓库还配套了自动化流水线，理解它能帮助贡献者预判"合并后会发生什么"：

• .github/workflows/build-readme.yml 每小时触发一次（cron 为0 * * * *），在 Node.js 20 环境下执行 updateCompletionTable.js 重新生成 README 中的完成度表格；若检测到文件变更，机器人（Bot-A0）会自动提交并推送"Update README table"的 commit。这意味着你新增的解法文件在合并后会被自动反映到 README 表格中。
• .github/workflows/stale._yml（文件名为stale._yml，从命名看处于停用状态）原本用于标记 30 天无活动的 stale issue/PR，7 天后关闭，并为带pending标签的 PR 豁免。

贡献清单速查

提交 PR 前，对照以下清单自查：

• 已在 README.md 的 Missing Solutions 表格确认该题目在你的目标语言下确实缺失
• 文件路径符合<language>/<problem-number>-name-of-problem.<language-extension>命名规范，题号补足四位
• 文件名大小写与同语言目录下现有文件风格一致，且不存在重复文件
• 代码已在 leetcode.com 上通过该题的提交评测
• 变量/方法使用语义化命名，代码风格清晰一致
• 若为第二解法，与已有解法在思路或复杂度上有实质区别，且使用可区分的方法名
• PR 标题简洁准确，格式如Create: 0001-two-sum.py
• 按 .github/pull_request_template.md 填写 File(s) Modified、Language(s) Used、Submission URL 三项
• 一个 PR 只包含一个解决方案/一处变更

遵循以上规范提交，你的解法不仅能被顺利评审合并，还有机会随仓库同步出现在 NeetCode 站点上，被全球的学习者引用。

【免费下载链接】leetcodeLeetcode solutions项目地址: https://gitcode.com/GitHub_Trending/leetcode1/leetcode