LeetCode 题解 (西法的刷题秘籍) — Admin & Contributor Guide

Audience: maintainers, forkers, translators, and contributors of azl397985856/leetcode. If you only want to read and study the material, see the User Guide. This guide covers the repository's architecture, build/publishing pipelines, content conventions, contribution workflow, licensing constraints, and operations.

1. Executive Summary

azl397985856/leetcode — branded 西法的刷题秘籍 ("Xifa's Problem-Solving Bible") and described in book.json as "leetcode题解，记录自己的leetcode解题之路" — is a content repository, not a software application. There is no runtime, no service, no test suite, and nothing to deploy. The "product" is a curated book of algorithm tutorials and LeetCode solutions authored by lucifer.

Of the 851 files in the repository, only ~18 are executable code (daily/answers/*.js and backlog/dp/bus-fare.py) — and those are illustrative LeetCode solutions, not application logic. Everything else is Markdown content and static assets. The repository is published through two parallel static pipelines: GitBook (HTML + EPUB/PDF/MOBI e-books) and Jekyll / GitHub Pages (HTML site).

Important

Treat this repo as a publication, not a codebase. The maintainer's daily work is editorial: writing solutions, reviewing PRs, keeping SUMMARY.md in sync, and managing translations — not building, testing, or shipping software.

2. Repository Architecture

Because there is no runtime, the meaningful "architecture" is the content flow from Markdown source to the two reader-facing channels.

 Authoring (Markdown + draw.io/Excalidraw sources)
        │
        │  SUMMARY.md defines order & inclusion
        ▼
 ┌──────────────────────────────┐        ┌────────────────────────────┐
 │  GitBook pipeline             │        │  Jekyll / GitHub Pages      │
 │  book.json + SUMMARY.md       │        │  _config.yml                │
 │  plugins: katex, ace          │        │  theme: jekyll-theme-cayman │
 │  → HTML site                  │        │  plugin: jekyll-relative-   │
 │  → EPUB / PDF / MOBI e-books  │        │    links                    │
 └──────────────────────────────┘        └────────────────────────────┘
        │                                        │
        ▼                                        ▼
  gitbook.io hosted book                   GitHub Pages site
  + offline e-book downloads               + raw GitHub Markdown view
        │
        └── images served from external CDN (p.ipic.vip) ─┐
                                                          ▼
                                          (operational dependency — see §11)

Directory layout

leetcode/
├── thinkings/     Chapter 1 — ~22 topic essays (bilingual; ~60 files incl. .en.md)
├── 91/            Chapter 2 — 91-day camp notes (README, binary-search, two-pointers, season2)
├── selected/      Chapter 3 — 9 multi-problem / big-company essays
├── collections/   Chapters 4-6 — easy.md / medium.md / hard.md indexes (+ easy.en.md)
├── problems/      ~400 files = ~250 distinct problems + English translations
├── daily/         每日一题 archive (46 dated entries) + answers/ (16 JS solutions)
├── templates/     Contribution scaffolds (problems/ + daily/)
├── backlog/       Planned content (精彩预告.md) + dp/bus-fare.py
├── assets/        Images, GIFs, draw.io (59) + Excalidraw (3) sources, Anki deck, cheatsheet.pdf
├── SUMMARY.md     GitBook table of contents (master index)
├── introduction.md  GitBook landing page (overrides README per book.json)
├── README.md / README.en.md   GitHub-facing project description
├── CONTRIBUTING.md / CONTRIBUTING.en.md   Contribution rules
├── epilogue.md / donation.md / thanksGiving*.md   Closing / sponsorship / milestones
├── book.json      GitBook config
├── _config.yml    Jekyll config
├── package.json   E-book build script + license
├── .mdlrc / .mdl_style.rb   markdownlint config
├── .nojekyll      Disables Jekyll processing in raw-Pages mode
├── cover.jpg      E-book cover
└── LICENSE.txt    CC BY-NC-ND 4.0

Note

.nojekyll and _config.yml coexist. .nojekyll tells GitHub Pages to serve files verbatim (no Jekyll); _config.yml configures Jekyll when it is used. Their coexistence reflects the project having been configured for both raw-Pages and Jekyll-processed builds at different times. The canonical hosted reader is the GitBook site, not GH Pages.

3. Content Model

The book presents as six chapters plus an epilogue (defined by SUMMARY.md), which map onto the author's stated five parts of the project.

Parts not surfaced as chapters: Anki cards (assets/anki/leetcode.apkg), daily problem (daily/), and backlog/plans (backlog/).

3.1 Problem-solution schema (the load-bearing contract)

Every problems/*.md file follows a fixed template. This schema is what makes the catalog navigable and is enforced editorially on new PRs. Per templates/problems/1014.best-sightseeing-pair.md, a solution must contain at least these seven sections:

Optional sections: 扩展 (Extensions), 相关题目 (Related problems), 参考 (References), plus a 复杂度分析 (Complexity analysis) block (time/space, KaTeX). Code fences must declare the language (```python, ```cpp, ```js, ```java, ```go). The contributing guide explicitly warns against inventing near-synonym headings (e.g. don't add "想法" when "思路" already means that) — consistency is mandatory.

3.2 Daily-problem schema

Per templates/daily/2019-06-03.md, each daily entry has: a 信息卡片 (info card) (date, problem link, comma-separated tag enum values like array/dp/math, statement), a 参考答案 (reference answer) (any language), an optional 扩展 (Extensions) block, and 其他优秀解答 (other excellent solutions) contributed by study-group members. Images go to assets/daily/; draw.io sources to assets/drawio/.

3.3 Topic-essay shape (thinkings/)

Topic essays are long-form narrative explainers (not templated like problems). A typical essay moves basic concepts → core idea → reusable templates → applications, illustrated heavily. They define formal vocabulary once (e.g. the binary-search essay establishes 解空间 / solution space) and reuse it across the chapter.

3.4 Bilingual convention

• Chinese (primary): name.md
• English: name.en.md

Translations are independent files, not generated. Coverage is complete across thinkings/, partial across problems/, and includes the easy collection (collections/easy.en.md). README.en.md is the English landing page.

4. Build & Publishing Pipeline

4.1 GitBook

book.json and SUMMARY.md drive the GitBook build. SUMMARY.md is the master table of contents: every page in the built book must be listed there (files not listed still render on GitHub/Jekyll but are absent from the GitBook output and e-books).

The only build automation declared in the repo is the book script in package.json:

{
  "scripts": {
    "book": "gitbook epub . && gitbook pdf . && gitbook mobi ."
  },
  "license": "CC BY-NC-ND 4.0"
}

npm run book        # builds EPUB, then PDF, then MOBI (sequential)

Tip

The combined script is &&-chained, so it aborts entirely if any one format fails. When debugging, run the formats individually — gitbook epub ., gitbook pdf ., gitbook mobi . — to isolate which backend broke.

Warning

The repo declares what to build but not the toolchain. In practice these commands require the legacy GitBook CLI (gitbook-cli), which GitBook has deprecated in favor of its hosted platform and which is finicky on modern Node.js — pin an older Node version if gitbook install/build crashes. PDF and MOBI output additionally rely on an external e-book converter (Calibre's ebook-convert) being on PATH. None of these versions/dependencies are pinned in the repo, so reproducing a build is the maintainer's responsibility. The hosted gitbook.io reader sidesteps the CLI entirely.

4.2 Jekyll / GitHub Pages

# _config.yml
theme: jekyll-theme-cayman
plugins:
  - jekyll-relative-links
relative_links:
  enabled: true
  collections: true
include:
  - SUMMARY.md
  - README.md

GitHub Pages runs Jekyll automatically on push; no manual build step is needed for the hosted Pages site.

Note

SUMMARY.md does double duty — GitBook TOC and a navigable index page under Jekyll. Keeping a single ordering file working for both pipelines is an intentional design choice; edit it carefully.

4.3 Markdown linting

.mdlrc points at .mdl_style.rb, which disables three rules to match the content's conventions:

all
exclude_rule 'MD033'   # raw HTML allowed (used to center images: the md spec can't)
exclude_rule 'MD036'   # emphasis-as-heading allowed (used for emphasis, not headers)
exclude_rule 'MD029'   # ordered-list prefix style relaxed (rule has a bug)

mdl .                                    # lint all Markdown
mdl problems/42.trapping-rain-water.md   # lint one file

Caution

Do not re-enable MD033 (no-raw-HTML) without first removing every <img ... >/<center>-style block — the repo uses raw HTML throughout to center images (the .mdl_style.rb comment says so explicitly). Re-enabling it would flag hundreds of intentional uses.

5. Configuration Reference

book.json

{
  "structure": { "readme": "introduction.md" },
  "title": "西法的刷题秘籍",
  "output": { "name": "西法的刷题秘籍" },
  "description": " leetcode题解，记录自己的leetcode解题之路。",
  "language": "zh-hans",
  "plugins": ["katex", "ace"],
  "pluginsConfig": {}
}

Other config files

Note

There are no application config files — no .env, no secrets, no service settings. ground_truth.cbf for this repo is empty; the four files above are the entire configuration surface.

6. System Requirements

7. Contribution Workflow

CONTRIBUTING.md defines four contribution types. All contributions are accepted upstream (PR into this repo); see §8 for why the license makes upstreaming, not forking-and-republishing, the right path.

7.1 Translation (翻译)

• Claim an untranslated file by opening an issue to reserve it.
• Name the English file foo.en.md alongside the Chinese foo.md.
• Prefer idiomatic (意译) translation over literal; leave proper nouns untranslated.

7.2 Multi-language solutions (贡献多语言)

• The approach must match the existing solution's logic; align naming where it matters.
• Naming may follow each language's best practice (snake_case for Python, camelCase for JS, …).
• Reference PR pattern: https://github.com/azl397985856/leetcode/pull/452/files.

7.3 New problem solution (增加题解)

A complete new-solution PR must touch all of these:

• [ ] The solution file problems/{number}.{slug}.md (following the 7-section schema in §3.1)
• [ ] An entry added to README.md at the correct difficulty/number position (with the marker)
• [ ] An entry in README.en.md (if you wrote an English solution)
• [ ] The draw.io source or image, if the solution has diagrams
• [ ] (Recommended) An entry in SUMMARY.md so the page appears in the GitBook build

Use templates/problems/1014.best-sightseeing-pair.md as the scaffold. For complex problems, diagrams are required.

Important

A file that exists but is not listed in SUMMARY.md renders fine on GitHub/Jekyll but is invisible in the GitBook build and e-books. Always update SUMMARY.md when adding pages destined for the book.

7.4 Daily problem (贡献每日一题)

• Submit via issue following the 每日一题 format, with correct tags (reuse LeetCode's official tags where possible).

8. Licensing & Reuse — read before forking

The project is licensed CC BY-NC-ND 4.0 (LICENSE.txt, also declared in package.json and both READMEs). The three clauses each carry real constraints:

Caution

The NoDerivatives (ND) clause is the one that surprises people. Under CC BY-NC-ND 4.0 you may produce an adaptation privately, but you may not Share Adapted Material — that includes a translated fork, a re-edited mirror, or a re-hosted modified copy. A literal verbatim mirror with attribution is allowed; a changed copy is not. This is why the project routes contributions (including translations) upstream as PRs: when you contribute back, your work becomes part of the original under the author's license rather than a prohibited derivative you redistribute yourself.

Practical guidance for downstream users:

• ✅ Read it, study from it, link to it, quote with attribution.
• ✅ Contribute translations/solutions as PRs to this repo.
• ⚠️ Mirroring verbatim (e.g. for an air-gapped class) is permissible with full attribution + license notice + a link back, and no modifications.
• ❌ Don't publish a modified/translated/re-branded fork, and don't use the content commercially.

9. Asset Management

Important

When updating a diagram, edit the .drawio/.excalidraw source in assets/, then re-export the PNG/JPG that the Markdown references. The README points contributors to assets/drawio/ for exactly this. Editing only the exported image leaves the source stale.

10. Security Considerations

A content repo's threat model is about content integrity and external dependencies, not running-service attacks.

Note

There is no credential, secret, or supply-chain (dependency) surface to speak of: the only package.json declares a single build script and no runtime dependencies. This is normal and correct for a content repo.

11. Operations

Editorial loop (the real "ops")

1. Author/curate a solution or essay following the §3 schemas.
2. Add it to README.md (+ README.en.md) and SUMMARY.md.
3. Place diagram sources in assets/; re-export images.
4. (Optional) mdl . to lint.
5. Publish: GitHub Pages updates automatically; regenerate e-books with npm run book when cutting a new download.

Recurring maintenance

• Link-rot sweep — periodically validate outbound links (blog, gitbook.io, OJ, image CDN). The image CDN (p.ipic.vip) is the highest-value thing to monitor.
• SUMMARY.md drift — verify every new problems//thinkings/ page is listed; orphaned pages silently vanish from e-books.
• Translation backlog — track which *.md files still lack *.en.md counterparts.
• Anki deck — the deck lags the content (issues #604/#597 noted ~10 cards); decide whether to expand or document the gap.
• Daily archive — the dated daily/ entries are historical (2019); the live daily problem now runs through the official site / WeChat, not the repo.

12. Improvements / Roadmap

Stated by the author (README "第五部分 — 计划"): the backlog (backlog/) is where future content destined for the solutions/topics/daily sections is staged before promotion.

Suggested operational improvements (not endorsed by upstream):

13. Troubleshooting (maintainer-side)

GitBook build issues

Jekyll / Pages issues

Markdownlint false positives

If mdl flags centered-image HTML or emphasis-as-heading, confirm .mdlrc references .mdl_style.rb and that MD033 / MD036 / MD029 are excluded there (they are, by default).

Known community issues (from the tracker)

Tip

For a content repo, GitHub issues are the troubleshooting and backlog goldmine — open 【专题】 and 【每日一题】 issues map directly to planned essays and daily problems; content-bug reports map to specific solution pages.

14. Quick Reference

Key files

Commands

npm run book                  # Build EPUB + PDF + MOBI (needs GitBook CLI; PDF/MOBI need a converter)
gitbook epub .                # Single-format build (debug-friendly)
mdl .                         # Lint all Markdown against .mdl_style.rb
bundle exec jekyll serve      # Local Jekyll preview (hosted Pages builds automatically)

Content naming conventions

Repository stats