指北 on September的个人空间

Git 与 GitHub 核心概念入门笔记

Sun, 24 May 2026 00:00:00 +0000

这篇是把一份 Git 与 GitHub 的长笔记重新整理成博客版。原笔记覆盖了从安装配置、初始化仓库，到分支协作、Pull Request、Cherry-pick、Stash、Rebase 等常用操作。

如果只想记住一句话：Git 负责记录代码历史，GitHub 负责把仓库放到网上协作。前者是版本控制工具，后者是代码托管和协作平台。

Git 和 GitHub 是什么

Git 是一个版本控制工具。它解决的问题是：文件改来改去以后，怎么知道每次改了什么、谁改的、什么时候改的，以及怎么回到之前的状态。

GitHub 是基于 Git 的代码托管平台。它把本地 Git 仓库放到云端，让别人可以浏览、下载、协作、提 Issue、提交 Pull Request。

可以简单理解为：

Git：本地版本管理系统
GitHub：远程仓库和协作平台
Repository：一个项目仓库
Commit：一次历史快照
Branch：一条开发线
Pull Request：请求别人合并你的改动

Git 不依赖 GitHub 也能用，但多人协作和开源项目通常会搭配 GitHub 一起使用。

准备工作

最基础的环境一般包括：

Git
VS Code
一个 GitHub 账号
可选：Codex、Claude Code 这类 AI coding agent

安装 Git 后，可以用下面命令确认：

1

git --version

新电脑第一次使用 Git，建议先配置用户名和邮箱：

1
2


git config --global user.name "你的名字"
git config --global user.email "你的邮箱"

这两个信息会写进每次提交记录里，用来标识这次 Commit 是谁提交的。

初始化仓库

把一个普通文件夹变成 Git 仓库，可以执行：

1

git init

执行后，文件夹里会出现一个隐藏目录：

1

.git/

这个目录保存了 Git 的全部版本信息。一般不要手动改它。删除 .git/，就相当于取消这个文件夹的 Git 管理。

在 VS Code 里，也可以通过 Source Control 面板点击 Initialize Repository 完成初始化。

.gitignore 忽略文件

并不是项目里的所有文件都应该提交。

常见需要忽略的内容包括：

.env：可能保存密钥、Token、数据库密码
node_modules/：依赖包体积大，可以通过 npm install 重新安装
构建产物：例如 dist/、build/
日志和缓存文件

可以在仓库根目录创建 .gitignore：

1
2
3
4


.env
node_modules/
dist/
*.log

原则是：源码、配置模板、文档应该提交；机器生成的临时文件、依赖目录、隐私密钥不要提交。

Commit 是一次快照

Commit 可以理解为给项目拍了一张快照。

一次完整的提交流程通常是：

1
2
3


git status
git add .
git commit -m "说明这次改了什么"

其中：

git status：看当前有哪些文件被修改
git add：把改动放进暂存区
git commit：把暂存区内容保存成一次历史记录

提交信息不要写成“修改”“更新”这种空话。更好的写法是描述这次改动的意图，比如：

1
2
3


git commit -m "Add prompt guide category filter"
git commit -m "Fix homepage sidebar link"
git commit -m "Translate RenPy interpolation guide"

以后回看历史时，Commit Message 是最快的索引。

工作区、暂存区、本地仓库、远程仓库

理解 Git 最重要的是理解几个区域。

区域	含义
Working Directory	当前文件夹里正在编辑的文件
Staging Area	准备提交的改动，也就是 `git add` 后的区域
Local Repository	本地保存的 Commit 历史
Remote Repository	GitHub 上的远程仓库

常见命令对应关系：

1
2
3
4


git add # 工作区 -> 暂存区
git commit # 暂存区 -> 本地仓库
git push # 本地仓库 -> 远程仓库
git pull # 远程仓库 -> 本地仓库并合并

很多 Git 问题，本质上是在问：这个改动现在在哪个区域？

撤销操作：Discard、Reset、Revert

Git 里有好几种“后悔药”，但它们适用场景不同。

操作	作用	适合场景
Discard	丢掉工作区未提交的改动	文件改坏了，还没 commit
Reset	把分支指针退回某个历史状态	本地历史需要重写，通常适合未推送的提交
Revert	生成一个反向提交来撤销旧提交	已经推送或多人协作时更安全

新手最容易混淆 reset 和 revert。

简单规则：

自己本地还没推送的提交，可以考虑 reset
已经推送到远程、别人可能基于它继续开发的提交，优先用 revert

revert 不会删除历史，而是新增一条“抵消旧改动”的提交，所以更适合团队协作。

Branch 分支

分支是另一条开发线。

常见用法是：主分支保持稳定，新功能放到单独分支开发。

1

git switch -c feature/login

开发完成后，再合并回主分支：

1
2


git switch main
git merge feature/login

分支的价值在于隔离风险。你可以在 feature 分支上尝试新功能，不影响 main 的稳定状态。

如果使用 VS Code 或 GitHub Desktop，也可以通过界面创建、切换和删除分支。

HEAD 是什么

HEAD 表示当前仓库指向哪一次提交。

通常情况下：

在 main 分支上，HEAD 指向 main 的最新提交
在 feature 分支上，HEAD 指向 feature 的最新提交
如果 checkout 到某个历史提交，可能进入 detached HEAD 状态

Detached HEAD 可以用来看历史代码，但不适合直接长期开发。需要继续改的话，最好从这个状态创建一个新分支。

Worktree 工作树

Worktree 可以让一个仓库同时拥有多个工作目录。

它适合这种场景：

常用命令：

1

git worktree add ../project-feature feature-name

AI coding agent 很适合搭配 worktree：每个任务一个独立工作树，互相不干扰，完成后再合并。

Merge Conflict 合并冲突

当两个分支修改了同一个文件的同一部分，Git 不知道该保留谁，就会产生冲突。

解决冲突不是“哪个按钮更高级”，而是人工判断最终文件应该长什么样。

一般流程：

打开冲突文件
找到冲突标记
保留正确内容
删除冲突标记
git add
git commit

冲突标记大概长这样：

1
2
3
4
5


<<<<<<< HEAD
当前分支内容
=======
另一个分支内容
>>>>>>> feature

在 VS Code 中可以选择保留当前、保留传入、两者都保留，但最终还是要确认合并后的代码是否合理。

Clone、Push、Pull

远程仓库最常用的三个动作是：

1
2
3


git clone <url>
git push
git pull

含义分别是：

clone：把 GitHub 上的仓库复制到本地
push：把本地提交推送到 GitHub
pull：把 GitHub 上的新提交拉到本地

如果你先在 GitHub 创建仓库，再复制到本地，一般用 clone。

如果你先在本地写了项目，再想传到 GitHub，就先 git init、commit，再添加远程仓库并 push。

GitHub 页面常用功能

GitHub 不只是放代码的网盘，它还有很多协作功能。

常用区域包括：

Code：查看代码、下载 zip、复制 clone 地址
Commit：查看提交历史
README：项目介绍，一般是仓库首页最重要的说明
Releases：发布版本和下载构建产物
Issues：提 bug、需求、讨论
Pull Requests：代码合并请求
Actions：自动化构建、测试和部署
Fork：把别人的项目复制一份到自己账号下
Star：收藏项目，也能反映项目热度

快捷键也很实用：

/：搜索仓库内容
t：快速找文件
.：在浏览器打开网页版 VS Code
?：查看 GitHub 快捷键

Fork 和 Pull Request

开源协作通常不是直接改别人的仓库，而是：

Fork：把仓库复制到自己账号
Clone：把自己的 fork 克隆到本地
Branch：创建新分支修改
Commit：提交改动
Push：推送到自己的远程仓库
Pull Request：请求原项目合并

Pull Request 不是单纯的“上传代码”，它也是讨论区。维护者可以 review 代码、提出修改意见，直到确认没问题再合并。

如果你是项目协作者，仓库管理员也可以直接把你加成 collaborator。这样你可以直接 push 到仓库，但更推荐仍然通过分支和 PR 保持审查流程。

Cherry-pick 精选提交

cherry-pick 用来把某几个 Commit 单独拿到当前分支。

例如 feature 分支有三次提交：

1
2
3


A 修按钮
B 改文案
C 加功能

你只想把 A 合到 main，不想要 B 和 C，就可以 cherry-pick A 的 Commit ID。

1

git cherry-pick <commit-id>

它适合“只挑某个改动”的场景，不适合替代正常合并流程。

Stash 临时存储

如果你正在改代码，突然需要切到另一个分支处理急事，但当前改动还不适合提交，可以用：

1

git stash

它会把当前未提交改动临时收起来，让工作区恢复干净。

回来以后再恢复：

1

git stash pop

Stash 适合临时切换任务，不应该长期当作保存代码的地方。真正有价值的进度还是应该 commit。

Rebase 变基

rebase 可以把一个分支的提交“挪到”另一个分支最新提交之后，让历史更线性。

例如：

1
2


git switch feature
git rebase main

效果是：feature 分支像是基于最新 main 重新开发出来的一样。

注意：rebase 会改写提交历史。
如果这个分支已经推送并且别人也在用，随便 rebase 再强推会影响别人。所以它更适合个人分支、尚未公开协作的分支。

简单规则：

自己一个人用的功能分支，可以 rebase
多人共用的公共分支，谨慎 rebase
主分支不要乱 rebase

AI 时代更要懂 Git

现在很多代码可以交给 AI agent 写，但 Git 反而更重要。

因为 AI 改代码很快，也可能一次改很多文件。如果没有 Git，你很难回答这些问题：

AI 到底改了哪些文件？
哪次改动引入了问题？
能不能只保留其中一部分？
能不能回到 AI 修改前的状态？
多个 AI 任务能不能并行？

所以 AI coding 的基础动作应该是：

1

一个任务 -> 一个分支或 worktree -> 小步 commit -> 审查 diff -> 再合并

不要让 AI 在一个长期混乱的工作区里连续改很多轮。每完成一个明确的小功能，就 commit 一次。这样即使后面改坏了，也能清楚地回退。

总结

Git 的核心不是背命令，而是理解版本流动：

1

工作区 -> 暂存区 -> 本地仓库 -> 远程仓库

GitHub 的核心也不是“上传代码”，而是围绕仓库建立协作流程：

1

Fork -> Branch -> Commit -> Push -> Pull Request -> Review -> Merge

掌握这些概念后，命令只是操作方式。无论是在 VS Code 里点按钮，还是让 AI agent 执行命令，本质都是在移动文件状态、提交历史和分支指针。

对新手来说，最值得先熟练的不是所有高级命令，而是这几件事：

会看 git status
会做小步 commit
会写清楚提交信息
会用分支隔离任务
会区分 discard、reset、revert
会把本地改动 push 到 GitHub
会通过 Pull Request 协作

这些掌握了，Git 和 GitHub 就不再是黑盒，而是你和 AI、队友、未来的自己协作时最可靠的底座。

把 Ren'Py 游戏翻译流程写成一个可复用 Skill

Sat, 23 May 2026 00:00:00 +0000

最近把一套 Ren’Py 游戏翻译流程整理成了一个 Codex Skill。它的作用不是“教 AI 怎么随便翻译几句文本”，而是把 Ren’Py 汉化里那些很容易被忽略的规则，变成一份可以反复执行的检查清单。

Ren’Py 游戏翻译看起来很简单：找到文本，翻成中文，保存。但真正做起来会发现，问题经常不在“这句话怎么翻”，而在“这句话到底会不会被 Ren’Py 正确匹配、正确加载、正确显示”。

所以这个 Skill 的核心思路是：不要把翻译当成纯文本替换，而要把它当成一个小型补丁工程。

为什么要写成 Skill

单次翻译靠经验可以做完，但下一次换一个游戏，很多坑还会再踩一遍。

比如：

old 字符串被改了一个空格，导致翻译完全匹配不上
菜单选项带了文字标签或状态后缀，生成的翻译没有覆盖真实显示内容
变量插值里的人名、阵营名仍然显示英文
字体不支持中文，结果游戏里全是方块
直接改原脚本，更新游戏后补丁很难迁移
批量脚本写文件时编码错了，中文变成乱码或问号

这些不是“翻译水平”问题，而是流程问题。Skill 适合处理的正是这种流程：每次遇到 Ren’Py 项目，都按同一套顺序检查、修改和验证。

工作区应该放在哪里

Ren’Py 翻译最重要的目录是：

1

game/tl/<language>/

Skill 里的第一条规则就是：优先在翻译目录里工作，能不改原始脚本就不改原始脚本。

原因很现实。原脚本是游戏本体的一部分，直接改它虽然快，但后续更新、分发、回滚都会变麻烦。更稳的方式是把翻译、字体、界面覆盖、语言按钮、默认语言设置等内容尽量放进 game/tl/<language>/。

这样做的好处是：

删除语言文件夹就能恢复原版
游戏更新时更容易迁移
补丁边界清楚
不容易误伤原游戏逻辑

如果原游戏没有 .rpy，只有 .rpyc 或资源包，那就先处理解包、反编译或生成翻译文件的问题，而不是直接乱改。

old/new 不能乱动

Ren’Py 里常见的翻译形式有两种。

一种是对话块：

1
2


translate chinese start_abc123:
 "这里写翻译后的台词"

另一种是字符串表：

1
2
3


translate chinese strings:
 old "Start"
 new "开始"

这里最容易犯的错是改 old。
old 不是给你润色的原文，它是 Ren’Py 用来匹配原始文本的钥匙。空格、标点、文本标签、大小写、换行都可能影响匹配。

所以规则很简单：

1
2


old 保持原样
new 写翻译

如果一个 old 看起来有点怪，比如带着 {size=}、颜色标签、状态后缀，也不要顺手清理。真实运行时显示出来的字符串很可能就是这么匹配的。

菜单和 UI 要单独查

Ren’Py 自动生成翻译文件很有用，但它不一定能覆盖所有运行时可见文本。

除了对话，还要主动搜索这些位置：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


Character("...")
text "..."
textbutton "..."
tooltip "..."
renpy.input("...")
renpy.notify(...)
default xxx = "..."
define xxx = "..."
$ xxx = "..."
menu:

尤其是菜单选项。它们经常带条件、标签、样式或自定义 screen 处理。你在翻译文件里看到的 old "Yes"，不一定覆盖了运行时真正显示的 {color=#fff}Yes{/color}。

如果某个选项死活不翻译，别先怀疑 Ren’Py。先把运行时原文和 old 逐字节对一下，包括空格和标签。

变量插值是隐藏大坑

这次整理 Skill 时，最值得单独记下的是变量插值。

Ren’Py 里常见写法是：

1

"Welcome to [tribe_name], [player_name]."

如果 tribe_name 的值是 "Wartribe"，即使你在字符串表里写了：

1
2


old "Wartribe"
new "战族"

最终显示时也不一定会自动变成中文。因为普通的 [tribe_name] 插值只是把变量当前值拿出来显示，不会必然再走一遍翻译表。

这种情况下要用翻译感知插值：

1

"欢迎来到 [tribe_name!t]，[player_name!t]。"

如果变量翻译后还需要继续插值，可以看情况用：

1

[variable!ti]

这个坑很隐蔽，因为外面的句子已经翻译了，只有嵌进去的人名、地名、阵营名还保留英文。看起来像漏翻，其实是插值方式不对。

高级补丁放 zzz.rpy

有些问题不是一句 old/new 能解决的，比如：

添加语言切换按钮
设置默认语言
替换字体
调整中文 UI 样式
覆盖 screen
修正少量源代码层面的文本

这类内容可以放到翻译目录里的补丁文件，例如：

1

game/tl/chinese/zzz.rpy

常见做法是加：

1

init offset = 1

让补丁比原定义更晚加载。这样可以覆盖 screen、style、define 等内容，又不会直接动原文件。

默认语言也要分清：

1

define config.default_language = "chinese"

这更适合“首次启动默认中文”。
如果用 config.language 强行指定语言，就可能变成每次启动都锁死语言，不一定符合玩家预期。

字体不是最后再想的事

中文翻译里，字体问题经常到最后才暴露：文本已经翻好了，进游戏一看全是方块。

Skill 里把字体和样式也放进检查范围。一般有几种处理方式：

在 translate <language> style 里覆盖样式
在 translate <language> python 里设置 GUI 变量
在 game/tl/<language>/ 下镜像放置字体资源
用 zzz.rpy 做语言限定的字体覆盖

关键是尽量让字体修复只影响目标语言，不要全局改坏原版 UI。

不要信任批量替换

批量脚本很诱人，尤其是翻译量大的时候。但 Ren’Py 文件里有很多结构性内容：

缩进
引号
转义符
文本标签
插值变量
%、\、/ 这类特殊符号

如果脚本没有严格按 UTF-8 读写，中文很容易变成乱码、问号或损坏标签。

所以 Skill 里明确写了：在 Windows 上做批量编辑时，要使用明确的 UTF-8 读写方式。改完后要扫一遍：

1
2
3
4
5


乱码
???? 
� 
损坏的 {tag}
损坏的 [variable]

翻译文件不是普通 Markdown，不能只看文本大概对不对。

验证要看三个文件

改完之后，不要只打开一两句台词看看。至少要检查：

1
2
3


errors.txt
traceback.txt
text_overflow.txt

它们分别对应不同问题：

errors.txt：生成或启动阶段的问题
traceback.txt：运行时崩溃
text_overflow.txt：文本溢出、排版放不下

还要实际测试：

主菜单
设置界面
语言切换
存档读档
代表性对话
选项菜单
字体显示
被覆盖的 label 或 screen

Ren’Py 翻译不是“文件能保存就完成”，而是“游戏运行时每条路径都能正确显示”。

这个 Skill 最有用的地方

我觉得它最有用的不是告诉 AI “请翻译成中文”，而是强迫 AI 先尊重 Ren’Py 的工程规则。

它会提醒我：

不要乱改 old
不要直接动原脚本
不要忽略菜单和 UI
不要忘记变量插值的 !t
不要把字体和排版当成收尾小事
不要跳过运行验证

这比单纯提高翻译文风重要得多。

总结

Ren’Py 游戏汉化本质上不是文本替换，而是一套围绕运行时匹配、语言加载、界面覆盖和补丁分发的工程流程。

把这套流程写成 Skill 之后，AI 就不只是“会翻译”，而是会按固定步骤处理项目结构、翻译文件、UI 字符串、变量插值、字体、补丁和验证。

下一次再做 Ren’Py 游戏翻译时，就不用从零回忆哪些坑要避开。直接让 Skill 接管检查清单，人只需要把关翻译质量和最终体验。

NotebookLM 做 PPT 的正确打开方式：先搭结构，再分章生成

Fri, 15 May 2026 00:00:00 +0000

最近看了一个 NotebookLM + Antigravity 的进阶教程，里面有一个点很适合单独拎出来写：不要把 NotebookLM 当成“一键生成 PPT”的按钮，而是把它当成一个能理解资料、拆解结构、辅助生产的外脑。

如果只是把一堆资料扔进去，然后直接让它生成 PPT，结果通常不会太理想。它会很快给你一份看起来完整的幻灯片，但页数有限、内容压缩严重，很多细节被省略。对于读书报告、课程展示、专题分享这种材料量比较大的任务来说，这种“一键生成”更像是摘要，不像是一份真正能拿去讲的 PPT。

更好的做法，是把 PPT 制作拆成几个阶段。

先让 NotebookLM 搭大纲

第一步不要急着生成幻灯片，而是先让 NotebookLM 读完资料，输出一个完整大纲。

这个大纲至少要包括：

整份 PPT 要分成几个章节
每个章节负责讲什么
每个章节大概需要几页
每页承担什么信息
整体的风格、语气和版式方向

这一步的意义是先拿到全局地图。AI 最容易犯的错误，不是不会写，而是在没有全局规划时把复杂内容压扁。先要结构，再要页面，后面的结果会稳定很多。

再按章节分批生成

NotebookLM 直接生成 PPT 时会遇到页数和信息密度的限制。如果材料很多，可以把生成任务拆开。

比如一份 60 页左右的专题 PPT，可以拆成：

第 1 章：背景与问题
第 2 章：核心概念
第 3 章：案例或文本分析
第 4 章：方法总结
第 5 章：结论与延伸

每次只让它生成其中一章。这样做有两个好处：一是绕开单次生成页数太少的问题，二是每一章能写得更细，不会被强行压缩成几页概述。

用固定提示词保持风格一致

分章生成的问题也很明显：如果每次提示词不一样，最后合起来就会像几份不同 PPT 拼在一起。

所以每次生成时，都应该复用同一套风格要求，例如：

标题层级保持一致
封面页、章节页和内容页的版式统一
配色和字体气质统一
每页信息密度接近
图文比例一致
不要突然切换成完全不同的设计风格

这部分可以理解成给 AI 一份“设计规范”。它不一定能百分百遵守，但有规范总比每次自由发挥要可靠。

最后人工合并和校对

AI 生成的内容不能直接当成最终稿。最后还要人工做一次整合。

我会重点检查这些地方：

章节之间有没有重复
页面顺序是否顺畅
每章开头和结尾是否能接上
标题风格是否统一
重点结论有没有被埋掉
有没有看起来很漂亮但实际上没信息量的页面

这一步很重要。AI 擅长把资料快速摊开，但最后的表达节奏还是要人来把关。PPT 不是资料堆叠，而是一次有顺序的讲述。

Antigravity 的作用

视频里另一个思路是把 NotebookLM 和 Antigravity 连起来，让一个工具负责理解资料，另一个工具负责操作、检索和自动化。

这种组合的价值在于：NotebookLM 更像资料库和阅读助手，Antigravity 更像可以执行任务的工作台。前者负责理解，后者负责行动。比如让它自动搜索资料、构建笔记本、整理来源，再反过来指导 PPT 或项目开发。

这其实是一个很有代表性的 AI 工作流变化：不是让一个工具包办全部，而是让多个 AI 工具各自做擅长的事。

我自己的理解

这套方法真正有用的地方，不在于“AI 可以帮我做 PPT”，而在于它把制作 PPT 的流程重新拆开了。

传统做法是：

1

找资料 -> 整理资料 -> 写大纲 -> 做页面 -> 改格式

一键生成的做法是：

1

塞资料 -> 生成 PPT

但更稳的 AI 工作流应该是：

1

塞资料 -> 生成结构 -> 分章生成 -> 统一风格 -> 人工整合

这比一键生成多了几步，但每一步都更可控。尤其是材料量大、主题复杂、最后还要公开展示的时候，可控性比速度更重要。

总结

NotebookLM 不应该只被当成 PPT 生成器。它更适合当成资料理解器、结构规划器和内容初稿生成器。

如果只是想快速做一份十几页的展示，一键生成当然够用。但如果想做一份真正能讲清楚问题的长 PPT，就应该先让它帮你搭结构，再分章生产，最后人工合并和润色。

AI 做 PPT 的关键不是“少点几下鼠标”，而是把原本混乱的资料整理过程变成一个更清晰的工作流。它节省的不是最后排版那一点时间，而是从资料到表达之间最消耗脑力的那段路。

清理c盘用软件

Sun, 19 Apr 2026 00:00:00 +0000

逮到一个很好用的C盘清理软件

https://privazer.com/zc/download.php

Markdown 基本语法指北

Mon, 06 Apr 2026 00:00:00 +0000

几乎所有现代的博客平台和静态网站生成器都完美支持 Markdown。它能让我们在纯文本环境下专注于内容创作，而无需被复杂的排版工具打断思路。

以下是日常写作中最常用的 Markdown 基本语法。

1. 标题 (Headings)

要在文档中创建标题，请在单词或短语前面添加井号 (#)。# 的数量代表了标题的级别。为了兼容性，请务必在 # 和标题文字之间保留一个空格。

1
2
3
4
5
6


# 一级标题
## 二级标题
### 三级标题
#### 四级标题
##### 五级标题
###### 六级标题

2. 段落与换行 (Paragraphs & Line Breaks)

段落： 创建段落非常简单，只需要使用一或多个空白行将连续的文本分隔开即可。不要用空格（spaces）或制表符（tabs）缩进段落。

换行： 如果你想在段落内强行换行（创建 <br>），请在这一行的末尾添加两个或多个空格，然后按回车键。

3. 强调语法 (Emphasis)

通过添加星号或下划线，可以轻松实现加粗和斜体效果。

加粗：在单词或短语的前后各添加两个星号或下划线。
- **加粗文本**
- __加粗文本__
斜体：在单词或短语的前后各添加一个星号或下划线。
- *斜体文本*
- _斜体文本_
加粗斜体：前后各添加三个星号或下划线。
- ***加粗且斜体的文本***

4. 引用 (Blockquotes)

要在段落前添加块引用，请在段落的第一行或者每一行前面添加一个 > 符号。引用不仅支持多段落，还可以嵌套其他 Markdown 元素。

1
2
3
4


> 这是一段引用文本。
> 
> > 这是一个嵌套的引用。
> > 里面还可以使用 **加粗** 等其他语法。

5. 列表 (Lists)

你可以将项目组织成有序列表或无序列表。

有序列表： 在每个列表项前添加数字并紧跟一个英文句点。数字不必按数学顺序排列，但列表应当以数字 1 起始。

1
2
3


1. 第一项
2. 第二项
3. 第三项

无序列表： 在每个列表项前添加破折号 (-)、星号 (*) 或加号 (+)。建议统一使用 -。

1
2
3


- 苹果
- 橘子
- 香蕉

6. 代码 (Code)

行内代码： 如果要把句子中的某个单词或短语标记为代码，请将其包裹在反引号 ( \ `) 中。

示例：使用 print("Hello World") 来输出文本。

代码块： 要创建多行代码块，请将代码包裹在三个反引号 (```) 中。在第一排的反引号后面加上编程语言的名称，就可以实现代码高亮。

1
2


def greet(name):
 print(f"Hello, {name}!")

7. 分隔线 (Horizontal Rules)

要创建一条水平分隔线，请在单独一行上使用三个或多个星号 (***)、破折号 (---) 或下划线 (___)，并且不能包含其他内容。

1

---

8. 链接 (Links)

链接文本放在中括号内，链接地址放在后面的括号内。

语法： [超链接显示名](超链接地址 "可选的提示标题")
示例： 欢迎访问我的 GitHub

如果想直接显示网址并使其可点击，可以用尖括号将网址括起来：<https://example.com>。

示例： https://blog.september.win/

9. 图片 (Images)

插入图片的语法和链接非常相似，只是前面多了一个感叹号 (!)。

语法： ![图片替代文字](图片链接地址 "可选的图片标题")
示例：

1

![美丽的风景图](https://markdown.com.cn/assets/img/philly-magic-garden.9c0b4415.jpg "Magic Gardens")

10. 转义字符 (Escaping Characters)

如果你需要显示原本用于格式化 Markdown 文档的字符（比如你不希望 # 变成标题），可以在该字符前面添加反斜杠 (\) 来转义。

1

\* 这不是一个无序列表项，而是一个普通的星号。

掌握了以上基本语法，你就已经具备了使用 Markdown 撰写结构清晰、排版优雅的博客文章的能力。

Markdown 拓展语法指北

Mon, 06 Apr 2026 00:00:00 +0000

掌握了基本语法后，Markdown 的扩展语法将为你打开新世界的大门。Markdown 官方标准（Basic Syntax）仅包含基础元素，但在实际应用中，许多解析器（如 GitHub Flavored Markdown, Hugo 等）支持更强大的扩展语法。掌握这些进阶技能，能让你轻松处理表格、代码高亮和任务清单。

1. 表格 (Tables)

要在 Markdown 中创建表格，请使用管道符 | 分隔各列，并使用三个或多个连字符 --- 创建表头和内容的分隔线。

对齐方式

通过在分隔线行添加冒号 :，可以控制列的对齐方式：

:---：左对齐（默认）
---:：右对齐
:---:：居中对齐

1
2
3
4


| 语法 | 说明 | 示例 |
| :--- | :---: | ---: |
| 表格 | 居中 | $10 |
| 扩展 | 左对齐 | $20 |

2. 围栏代码块 (Fenced Code Blocks)

扩展语法允许你使用三个反引号（```）或三个波浪号（~~~）来包裹多行代码。最强大的功能是支持语法高亮，只需在开头反引号后指定语言名称（如 python, html, css 等）。

1
2
3
4


{
 "project": "September's Blog",
 "status": "Learning Markdown"
}

3. 脚注 (Footnotes)

脚注用于对正文中的内容添加补充说明，而不会打断读者的阅读流。

用法：在词汇后面使用 [^1]，然后在文档底部定义说明。
示例：这是一个使用了脚注的句子。¹

4. 标题 ID (Heading IDs)

部分解析器支持给标题指定唯一的 ID，方便在文章内部进行跳转（锚点链接）。

1

### 我的目标 {#goals}

5. 定义列表 (Definition Lists)

定义列表允许你列出术语及其对应的定义。

1
2
3
4
5
6


第一项
: 这是第一项的定义。

第二项
: 这是第二项的定义。
: 这是第二项的另一个定义。

6. 删除线 (Strikethrough)

在文字前后各添加两个波浪号 ~~ 来表示已被删除或错误的信息。

示例：~~这件衣服原价 99 元~~，现在只需 19 元。

7. 任务列表 (Task Lists)

任务列表非常适合管理待办事项或项目进度。使用带有空格或 x 的中括号 [ ]。

1
2
3


- [x] 完成基础语法学习
- [x] 掌握扩展语法
- [ ] 发布第一篇技术博客

8. 使用 Emoji 表情

在 Markdown 中添加表情有两种常见方式：

直接从表情库复制并粘贴 Emoji 符号（如 🚀）。
使用“短代码”（需解析器支持），例如输入 :smile: 会被渲染成 😄。

9. 自动网址链接 (Automatic URL Linking)

许多现代解析器会自动将纯文本形式的 URL（如 https://google.com）直接转换为可点击的超链接，而无需额外添加中括号。

通过灵活运用这些扩展语法，你的 Markdown 文档将不仅仅是文字，更是一个具备专业排版水准的数字化作品。

这些扩展语法能显著提升你博客内容的专业度和丰富度。建议在使用前，先确认你所使用的博客主题或编辑器是否已完整开启这些功能支持。

这是在文档末尾自动生成的补充说明。 ↩︎