用 git diff 生成补丁最可靠：未暂存改动用 git diff > patch，已暂存用 git diff --cached > patch，含新建文件需先 git add -n；vscode 终端执行更稳，避免插件问题；打补丁用 git apply 并注意换行、路径、编码一致性。
用 git diff 生成当前未提交的修改补丁
VSCode 本身不提供“导出 patch”按钮，但底层依赖 Git，所以最直接的方式是调用 git diff。它能精准捕获工作区与 HEAD 的差异，适合无网络时打包改动。
操作前确认：你已 git init 项目，且所有要打包的文件都处于未暂存或已暂存状态（git status 可见）。
- 只导出已暂存的修改（即
git add过的）：git diff --cached > my-change.patch - 导出全部未提交改动（含未暂存）：
git diff > my-change.patch - 若只想包含某几个文件：
git diff path/to/file1.js path/to/file2.css > partial.patch
注意：git diff 默认不含新建的未跟踪文件（untracked），如需一并打包，得先 git add -N 告诉 Git “我知道这些文件存在”，再用 --cached 输出。
VSCode 内置终端里执行命令更稳，别依赖插件
很多用户搜“VSCode patch 插件”，结果装了不维护的扩展，反而导出格式错乱或漏二进制文件。真实场景中，插件在离线环境还可能缺依赖、报 command 'xxx.patchExport' not found 错误。
直接用 VSCode 底部集成终端（Ctrl+`）执行命令，路径自动对齐当前工作区，无需手动 cd，也避开了插件权限、沙箱、Git 路径识别不准等问题。
- 确保终端里
git --version有输出，否则补丁内容为空或报错fatal: not a git repository - 补丁文件名建议带日期和简短描述，例如：
fix-login-20240521.patch，方便后续 apply 时识别 - 生成后用
head -n 5 my-change.patch快速确认开头是diff --git行，不是空文件或 HTML 错误页
git apply 在目标机器上打补丁的实操要点
补丁文件传到另一台没网络的机器后，不能双击打开，必须用 git apply 回放。它比 patch -p1 更安全——会校验文件是否存在、行号偏移是否合理，失败时不破坏原文件。
- 进入目标仓库根目录再执行：
git apply /path/to/my-change.patch - 如果提示
error: patch failed，大概率是目标代码版本和生成 patch 时的HEAD不一致，加--reject让它把冲突部分写成.rej文件，人工核对 - 想预览但不真正应用？加
--check参数：git apply --check my-change.patch，返回 0 表示可干净打上 - 补丁里含新建文件，但目标机上该路径父目录不存在？
git apply默认不自动建目录，需提前mkdir -p，或改用git am（需配合git format-patch生成）
中文路径、换行符、权限变更容易让 patch 失效
离线传补丁最常踩的坑不在 Git 命令本身，而在环境细节。Windows 和 Linux 之间传 patch，或 VSCode 设置了 "files.eol": "\r\n"，都会让 git diff 输出带 ^M，导致 git apply 拒绝应用。
- 统一用 LF 换行：在 VSCode 设置里关掉
files.autoSave，保存前按Ctrl+Shift+P→ 输入 “Change End of Line” → 选LF - 避免中文路径参与 diff：生成 patch 前，把含中文的文件
git mv成英文名，打完补丁再改回来（否则git apply可能报invalid path） - 权限变更（如
chmod +x）默认不被git diff记录，如需传递，显式加参数：git diff -p --no-index --chmod（较少用，多数场景忽略即可）
补丁本质是文本快照，不是魔法。它只忠于生成那一刻的 Git 状态，任何路径、换行、编码的微小偏差，都会让 apply 卡在第一行。多看一眼 my-change.patch 的前三行，比重试十次更有用。
