4、patch命令实战：patch命令的基本用法、应用补丁（-p0, -p1）、回退补丁（-R）、干运行模式（--dry-run）
聊完了 diff 怎么生成补丁，接下来就是重头戏了——怎么把补丁打上去。patch 命令，说白了就是 diff 的搭档。一个负责生成差异，一个负责应用差异。我刚开始用的时候总觉得这俩是同一个工具的两个面，用多了才发现，patch 的坑其实比 diff 多得多。
今天我们就来把 patch 的几种核心用法捋一遍。你跟着我走一遍，基本就能应付日常工作中 90% 的场景了。
4.1 patch 命令的基本用法
patch 的语法其实很直白：
patch [选项] [原始文件] < 补丁文件或者更常见的写法是：
patch -p数字 < 补丁文件嗯，这里要注意一个细节：patch 默认会直接修改原文件。也就是说，你执行完命令，原文件就被改了。没有备份的话，想恢复就只能靠 -R 回退了。
我个人习惯是，在打补丁之前，先把原文件备份一份：
cp main.c main.c.bak
patch < fix.patch这样万一出问题，还能救回来。别问我为什么有这个习惯——有一次我在生产环境上打补丁，手一抖打错了位置，整个文件乱掉，幸亏有备份才没酿成大祸。
4.2 应用补丁：-p0 与 -p1 的区别
这是 patch 命令里最容易让人迷糊的地方。我见过不少新手在这里栽跟头。
先看一个典型的 diff 输出：
--- a/src/main.c
+++ b/src/main.c这里的 a/src/main.c 和 b/src/main.c 是 diff 自动生成的路径。但实际你的项目目录里，可能没有 a/ 和 b/ 这两个前缀目录。
-p0 的含义：保留完整路径，不做任何剥离。也就是说，patch 会直接去找 a/src/main.c 这个文件。如果你的当前目录下没有 a/ 这个文件夹，那就会报错。
-p1 的含义：剥离最前面的一层目录。也就是把 a/src/main.c 变成 src/main.c。这是最常用的用法。
我画了一张图，帮你理解这个剥离过程：
举个例子你就明白了。假设你的项目结构是这样的：
~/project/src/main.c补丁文件里写的是：
--- a/src/main.c
+++ b/src/main.c如果你在 ~/project 目录下执行：
patch -p0 < fix.patch→ 它会去找~/project/a/src/main.c，找不到，报错。patch -p1 < fix.patch→ 它会去找~/project/src/main.c，找到了，成功。
所以，绝大多数情况下，用 -p1 就对了。除非你明确知道补丁文件里的路径就是真实路径，才用 -p0。
我的小技巧：如果你不确定该用 -p0 还是 -p1，先用 --dry-run 试一下。后面会讲这个选项。
4.3 回退补丁：-R 选项
打补丁打错了怎么办？或者你想撤销这次修改？patch 提供了 -R 选项，用来反向应用补丁。
说白了，就是把补丁里的「加」变成「减」，「减」变成「加」。原来删掉的行会被加回来，原来加进去的行会被删掉。
用法很简单：
patch -R -p1 < fix.patch或者：
patch -Rp1 < fix.patch我曾经在一个项目里，连续打了三个补丁，结果发现第二个补丁有问题。当时我直接用了 -R 回退第二个补丁，然后再重新打修正后的版本。整个过程不到一分钟，比手动改文件快多了。
不过要注意一点：-R 只能回退之前用 patch 打上去的补丁。如果你手动修改过文件，或者中间有其他操作改变了文件内容，-R 可能会失败。因为 patch 需要找到和补丁里完全匹配的上下文才能反向操作。
避坑提醒：我曾经试过在文件已经被手动修改后，再用 -R 回退补丁。结果 patch 报了一堆冲突，文件变得乱七八糟。所以，回退补丁之前，最好确认文件没有被额外改动过。
4.4 干运行模式：--dry-run
这个选项是我最常用的，没有之一。
--dry-run 的意思是「模拟运行」。patch 会假装打补丁，但实际上不会修改任何文件。它会告诉你哪些地方能成功，哪些地方会失败。
用法：
patch --dry-run -p1 < fix.patch输出示例：
checking file src/main.c
Hunk #1 succeeded at 15.
Hunk #2 succeeded at 42.
Hunk #3 FAILED at 78.
1 out of 3 hunks FAILED -- saving rejects to file src/main.c.rej看到 FAILED 了吗？这说明第三个块（hunk）打不上去。patch 会把失败的部分保存到 .rej 文件里，方便你手动处理。
我个人的工作流程是这样的：
- 拿到补丁文件后，先
patch --dry-run -p1 < fix.patch看看能不能打上。 - 如果全部成功，再正式执行
patch -p1 < fix.patch。 - 如果有失败，先分析
.rej文件，手动解决冲突。
你想想看，如果没有 --dry-run，直接打补丁，万一失败了，文件可能已经被部分修改了。到时候想恢复都麻烦。所以，先模拟，再执行，这个习惯一定要养成。
4.5 综合实战：一个完整的例子
我们来走一遍完整的流程。假设我有一个项目，目录结构如下：
myapp/
├── src/
│ └── hello.c
└── patch/
└── fix-hello.patch补丁文件 fix-hello.patch 的内容：
--- a/src/hello.c
+++ b/src/hello.c
@@ -1,5 +1,6 @@
#include <stdio.h>
int main() {
- printf("Hello, World!\n");
+ printf("Hello, Patch!\n");
+ printf("This is a test.\n");
return 0;
}现在我在 myapp/ 目录下执行：
# 第一步：干运行，看看能不能打上
patch --dry-run -p1 < patch/fix-hello.patch
# 输出：checking file src/hello.c
# Hunk #1 succeeded at 5.
# 全部成功，继续
# 第二步：正式打补丁
patch -p1 < patch/fix-hello.patch
# 第三步：验证文件内容
cat src/hello.c
# 第四步：如果发现打错了，回退
patch -R -p1 < patch/fix-hello.patch这个流程看起来简单，但每一步都有它的意义。尤其是 --dry-run 和 -R，这两个选项能帮你避免很多麻烦。
4.6 常见问题与避坑指南
| 问题 | 原因 | 解决方法 |
|---|---|---|
| patch 报错 "No file to patch" | -p 参数不对，路径找不到 | 检查 -p0 还是 -p1，或者用 --dry-run 测试 |
| patch 报错 "Hunk #1 FAILED" | 文件内容与补丁不匹配 | 检查文件版本，或者手动处理 .rej 文件 |
| 回退时 patch 报错 "malformed patch" | 补丁文件格式有问题 | 检查补丁文件是否被修改过，或者重新生成 |
| 打补丁后文件乱码 | 补丁文件编码不一致 | 确保补丁文件和源文件编码一致（推荐 UTF-8） |
我的经验：如果你经常需要打补丁，建议写一个简单的脚本，把 --dry-run 和正式执行打包在一起。比如：
#!/bin/bash
PATCH_FILE=$1
echo "模拟运行..."
patch --dry-run -p1 < "$PATCH_FILE"
if [ $? -eq 0 ]; then
echo "模拟成功，正式打补丁..."
patch -p1 < "$PATCH_FILE"
else
echo "模拟失败，请检查补丁文件"
fi这样每次打补丁就只需要执行一个命令，省心不少。
好了，patch 的基本用法就这些。记住几个关键点：-p1 最常用，--dry-run 先模拟，-R 能回退。掌握了这些，你就能在大多数场景下游刃有余了。