Git自动合并的静默风险与语义冲突防御指南

1. 项目概述：当 Git 自动合并“自作主张”时，你在哪一环失去了控制权？

Git 的 Auto Merge（自动合并）不是某个独立命令，而是git merge、git pull、甚至git rebase --autostash在特定条件下触发的一套隐式决策机制。它不声不响地把两个分支的变更缝合在一起，表面看是省事，实则像在暗流中驾驶——风平浪静时一切如常，一旦分支历史出现分叉、冲突标记被忽略、或合并策略被误配，它就可能直接生成一个逻辑错误但语法合法的提交，而你直到三天后线上报错才意识到：那个“自动通过”的合并，其实悄悄删掉了关键配置项、覆盖了某次重要修复，或者把测试环境的调试日志混进了主干。

我第一次踩坑是在一个跨团队协作的微服务项目里。A 同学在feature/user-auth分支上重构了登录校验逻辑，B 同学在hotfix/db-timeout分支里紧急修复了数据库连接超时参数。两人几乎同时向develop提交 PR，CI 系统自动执行git merge develop进行预检。结果 CI 通过了，但上线后用户无法登录——排查发现，feature/user-auth中新增的 JWT 密钥加载逻辑，被hotfix/db-timeout中一条看似无关的config.load()调用覆盖了，因为后者在merge时被 Git 判定为“上游变更”，自动选中了它的版本。这不是冲突（conflict），而是静默覆盖（silent override）——Git 认为两处修改不重叠，于是“合理”地保留了双方代码，却没意识到它们在运行时存在强依赖关系。

这就是 Auto Merge 最危险的地方：它只做文本层面的差异比对与行级合并，完全不理解业务语义。它不会告诉你“这个函数签名变了，调用方需要同步更新”，也不会警告“这两个配置项必须成对出现”。它只忠实地执行三路合并（three-way merge）算法，而你，作为开发者，就是那个最终为算法输出背书的人。

这篇文章不讲基础命令怎么用，也不堆砌git config --global merge.ff only这类配置项。我要带你一层层剥开 Git 自动合并背后的决策树：它到底在什么条件下启动？哪些参数会改写它的默认行为？为什么有时候它连冲突都不报，就直接生成一个“看似正确”的坏提交？更重要的是，那些被官方文档轻描淡写带过的“边缘情况”——比如子模块变更、符号链接处理、换行符自动转换、甚至文件权限位变化——如何在真实项目中酿成线上事故。我会用真实操作日志还原问题现场，给出可直接复现的测试用例，并附上我们团队现在强制执行的四道合并前检查清单。如果你经常在 PR 合并后收到“昨天还好的，今天怎么就挂了”的消息，或者 CI 通过但 QA 环境立刻崩掉，那这篇内容就是为你写的。

2. Auto Merge 的触发逻辑与底层机制拆解

2.1 它不是“功能”，而是 Git 合并策略的默认行为集合

很多人误以为git merge --auto是一个真实存在的命令，其实 Git 命令行中根本不存在这个 flag。所谓“Auto Merge”，是 Git 在执行git merge <commit>或git pull（本质是git fetch + git merge）时，根据当前工作区状态、目标提交的拓扑关系、以及本地配置，自动选择最合适的合并策略与执行路径的结果。它没有开关，只有条件。理解这些条件，才是掌控它的起点。

Git 的合并流程本质上是一个三步判断：

1. 快进判断（Fast-Forward Check）：如果当前分支指针（HEAD）是目标提交的直接祖先，Git 认为无需创建新提交，只需将 HEAD 指针“快进”到目标提交。这是最干净的合并，无新 commit，无冲突可能。例如：

   # 当前在 develop 分支，最新提交是 A # origin/develop 已更新到提交 B，且 B 是 A 的直接后代 # 执行 git pull origin develop # Git 直接将 develop 指针从 A 移动到 B，完成“自动合并”

2. 三方合并准备（Three-Way Merge Setup）：如果无法快进（即存在分叉），Git 会寻找两个分支的最近共同祖先（Merge Base）。这个过程本身不产生冲突，但决定了后续合并的“参考点”。例如：

   A---B---C (main) \ D---E (feature)

   合并feature到main时，Git 会找到A作为 merge base，然后比较A..C（main 的变更）和A..E（feature 的变更）。

3. 合并策略执行（Merge Strategy Execution）：这才是 Auto Merge 的核心。Git 根据变更内容的性质，自动选择内置策略：

   • resolve：默认策略，用于简单线性历史。
   • recursive：最常用策略，也是git merge的默认值。它能处理多个父提交（如已存在合并提交的分支），并支持-X参数（如-X ours,-X theirs）来指定冲突解决倾向。
   • octopus：当一次合并多个分支时启用（如git merge branch1 branch2 branch3）。
   • subtree：用于子树合并场景。

提示：你可以用git merge --no-commit --no-ff <branch>强制跳过快进，并禁用自动提交，从而在合并前检查暂存区状态。这是最有效的“防坑前置动作”。

2.2 那些让你猝不及防的“非冲突型”静默覆盖

真正的坑往往不在红色报错里，而在绿色的Auto-merging xxx日志背后。以下是三种最典型的静默覆盖场景，它们都符合 Git 的“无冲突”定义，却在业务层面造成严重破坏：

场景一：同名文件，不同语义的“安全”覆盖
假设项目中有config/app.yaml，main分支定义了生产环境的数据库地址：

# main 分支的 app.yaml database: host: prod-db.example.com port: 5432

feature/payment分支为了本地调试，改成了：

# feature/payment 分支的 app.yaml database: host: localhost port: 5432 debug: true # 新增字段

当feature/payment合并回main时，Git 发现host字段被修改，debug字段是新增，无行级冲突。它会生成一个合并后的文件，其中host取feature分支的localhost，debug: true也被保留。结果：生产构建使用了这个合并文件，数据库连接直接指向了本地，而debug: true可能触发了敏感日志全量打印。Git 认为这很“安全”，因为它只看到文本差异，看不到“host字段的值决定了运行环境”这一业务约束。

场景二：函数内部逻辑的“无害”叠加
main分支的utils.js中有一个工具函数：

function calculateTotal(items) { return items.reduce((sum, item) => sum + item.price, 0); }

feature/discount分支在同一函数内添加了折扣逻辑：

function calculateTotal(items) { const base = items.reduce((sum, item) => sum + item.price, 0); return base * 0.9; // 九折 }

Git 合并时，会将两者视为对同一函数体的修改。由于reduce行和return行都发生了变化，Git 无法进行行级匹配，于是它会将整个函数块标记为冲突——等等，这应该报冲突啊？别急，如果feature/discount分支的修改是这样写的：

function calculateTotal(items) { return items.reduce((sum, item) => sum + item.price, 0) * 0.9; }

那么 Git 就可能认为：main的return行被feature的return行“完全替换”，没有重叠修改，因此无冲突。结果是折扣逻辑被应用，但main分支中可能存在的其他计算逻辑（比如税费加总）被彻底抹去。这种覆盖，比报冲突更危险，因为它不会打断你的流程。

场景三：二进制文件与元数据的“不可见”变更
Git 对二进制文件（如.png,.jar）的合并策略是：如果两个版本不同，且无法 diff，则直接拒绝合并，要求手动解决。但对某些“类文本”元数据，它却会静默处理：

• 文件权限：main分支中script/deploy.sh是644（不可执行），feature/ci分支将其改为755（可执行）。Git 默认会以feature分支的权限为准，完成合并。如果你的 CI 流水线恰好依赖这个脚本的可执行位，而main分支的历史中它一直不可执行，那么合并后脚本突然可执行，可能导致流水线跳过某些安全检查步骤。
• 换行符（CRLF/LF）：在 Windows 和 Linux 混合开发环境中，core.autocrlf配置不当会导致 Git 在检出时自动转换换行符。main分支在 Linux 上提交的是 LF，feature分支在 Windows 上提交的是 CRLF。Git 合并时，会将两者都标准化为 LF（如果配置为true），这本身没问题。但如果feature分支的代码里有正则表达式/\r\n/显式匹配 CRLF，那么合并后该正则将永远失效，而 Git 不会提示任何问题。

注意：这些场景的共同点是——它们都绕过了 Git 的冲突检测机制。Git 的冲突检测基于“同一行或相邻行被两个分支修改”，而上述问题要么是语义冲突（同一字段不同含义）、要么是结构冲突（函数体整体重写）、要么是元数据冲突（权限、换行符）。要防御它们，不能只靠git status，必须引入语义层的检查。

2.3 影响 Auto Merge 行为的四大核心配置项

Git 的自动合并行为并非铁板一块，它受一系列全局、系统、仓库级配置的精细调控。理解这些配置，等于拿到了控制 Auto Merge 的遥控器。

这些配置不是“高级技巧”，而是现代团队协作的基础设施。我见过太多团队，因为没统一core.autocrlf，导致同一个配置文件在不同人电脑上git diff结果完全不同，最后在 CI 上构建失败，排查数小时才发现是换行符惹的祸。配置本身很简单，难的是推动团队达成共识并落地。

3. 核心细节解析与实操要点：从原理到防御

3.1 三路合并（Three-Way Merge）的完整推演过程

要真正理解 Auto Merge 的“思考过程”，我们必须亲手走一遍三路合并的每一步。下面以一个可复现的最小案例，用git log --graph --oneline --all和git show命令，还原 Git 内部的决策链。

第一步：构建测试场景

# 初始化仓库 mkdir git-merge-demo && cd git-merge-demo git init echo "v1" > README.md && git add . && git commit -m "init" # 创建 main 分支并添加一行 git checkout -b main echo "line1" >> README.md && git add . && git commit -m "main: add line1" # 创建 feature 分支，基于 init 提交 git checkout -b feature HEAD~1 echo "line2" >> README.md && git add . && git commit -m "feature: add line2"

此时仓库状态为：

* 8a3c1d2 (feature) feature: add line2 | * 5b7e9f1 (main) main: add line1 |/ * 1a2b3c4 init

第二步：执行合并并定位 merge base

git checkout main git merge feature

Git 会执行以下步骤：

1. 寻找 merge base：git merge-base main feature返回1a2b3c4（init 提交）。
2. 生成三方 diff：
   • git diff 1a2b3c4 main：显示main分支相对于基线的变更（即增加line1）。
   • git diff 1a2b3c4 feature：显示feature分支相对于基线的变更（即增加line2）。
3. 应用合并算法：Git 将基线文件（v1）作为模板，将main的变更（line1）和feature的变更（line2）“叠加”上去。由于两者修改的是文件的不同位置（line1在第二行，line2在第二行，但基线只有一行，所以 Git 会将它们视为追加），最终得到：

   v1 line1 line2

   这就是无冲突合并的结果。

第三步：验证合并结果的“合理性”

cat README.md # 输出： # v1 # line1 # line2 git log --graph --oneline --all # 输出： # * 9d4e5f6 (main) Merge branch 'feature' # |\ # | * 8a3c1d2 (feature) feature: add line2 # * | 5b7e9f1 main: add line1 # |/ # * 1a2b3c4 init

这个例子展示了 Git 的“乐观合并”哲学：只要变更不重叠，就默认它们是兼容的。但请注意，这个“兼容”是基于行号偏移的，而不是基于语义逻辑的。如果main分支的line1是database.host: prod，而feature分支的line2是database.host: localhost，那么 Git 依然会把它们都加进去，生成一个语法错误的 YAML 文件。这就是为什么我们必须在 Git 之上，构建语义层的防护网。

3.2 子模块（Submodule）合并的特殊陷阱

子模块是 Git 中最易被低估的复杂特性之一。它的合并逻辑与普通文件截然不同，且错误往往在数周后才暴露。

子模块的本质：子模块不是一个文件夹，而是一个指向另一个 Git 仓库特定提交的指针。它在父仓库中以.gitmodules文件（记录 URL 和路径）和.git/config中的submodule.<name>.url配置存在，其实际内容存储在.git/modules/<name>/下。

合并时的三大风险点：

1. 指针漂移（Pointer Drift）：main分支的子模块指向lib-a@commit-A，feature分支将其更新为lib-a@commit-B。合并后，父仓库的子模块指针会变成commit-B。但如果commit-B中存在一个未被发现的内存泄漏 bug，而main分支之前一直稳定运行在commit-A，那么合并就悄无声息地引入了故障。
2. 初始化缺失（Uninitialized Submodule）：feature分支的开发者在本地执行了git submodule update --init，但忘记git add .gitmodules和git commit。当其他人拉取这个feature分支并尝试合并时，Git 会报告子模块路径存在但未初始化，导致构建失败。这不是 Git 的错，而是工作流的断点。
3. 递归合并的“黑洞”：git merge --recurse-submodules会尝试递归地合并子模块。但这要求子模块本身也处于一个可合并的状态（即有共同祖先）。如果main和feature分支的子模块分别指向了两个完全无关的仓库（例如，一个 fork 了一个库，另一个 fork 了另一个库），那么递归合并会直接失败，且错误信息极其晦涩。

防御方案：强制子模块状态检查在 CI 流水线的构建脚本开头，加入以下检查：

#!/bin/bash # 检查子模块是否全部初始化且状态一致 if [ -f ".gitmodules" ]; then # 1. 确保所有子模块都已克隆 git submodule sync --quiet git submodule update --init --recursive --quiet # 2. 检查是否有未提交的子模块变更（即子模块工作区被修改） if git submodule status | grep '^+'; then echo "ERROR: Submodule has uncommitted changes. Please commit or stash them." exit 1 fi # 3. 检查子模块是否处于干净状态（无未追踪文件、无修改） git submodule foreach --quiet 'if ! git status --porcelain | grep -q "^"; then :; else echo "Submodule $(basename $path) is dirty"; exit 1; fi' fi

这段脚本会在每次构建前，确保所有子模块都已正确初始化、指向预期提交、且自身工作区干净。它把子模块的“不确定性”提前暴露在构建阶段，而不是等到线上崩溃。

3.3 合并前的四道人工检查清单（我们团队的 SOP）

再强大的自动化也无法替代人的判断。我们团队在每个 PR 合并前，强制执行以下四道检查，缺一不可。这不是形式主义，而是用结构化的问题，逼迫开发者进行一次“合并前的代码走查”。

检查一：变更范围确认（Scope Sanity Check）

• 问题：git diff origin/main...HEAD显示的变更，是否严格限定在本次 PR 的描述范围内？
• 操作：在 GitHub/GitLab 的 PR 页面，点击 “Files changed” 标签页，逐个展开所有被修改的文件，快速扫视。特别注意：
  • 是否有package-lock.json、yarn.lock等锁文件被意外更新？（这可能意味着依赖树发生了未声明的变更）
  • 是否有config/目录下的文件被修改？（配置变更需单独评审）
  • 是否有Dockerfile或Makefile被修改？（构建流程变更影响深远）
• 为什么重要：很多“神秘 bug”源于一个被忽略的锁文件更新，它悄悄升级了一个有已知 bug 的依赖版本。

检查二：语义冲突扫描（Semantic Conflict Scan）

• 问题：本次修改的函数、类、配置项，是否与origin/main中的同名实体存在潜在的语义冲突？
• 操作：在本地执行：

  # 查找所有被修改的函数名（以 JavaScript 为例） git diff origin/main...HEAD -- '*.js' | grep 'function ' | sed 's/.*function \([^ ]*\).*/\1/' | sort -u # 然后，在 IDE 中全局搜索这些函数名，查看 `origin/main` 中的定义

• 重点看：
  • 函数签名是否改变？（参数增减、类型变化）
  • 返回值结构是否改变？（如从{ success: true }变为{ data: {}, error: null }）
  • 配置项的 key 名称或层级是否改变？（如api.timeout->api.request.timeout）
• 为什么重要：Git 只管文本，不管契约。函数签名的微小变化，可能让所有调用方崩溃。

检查三：测试覆盖率验证（Test Coverage Validation）

• 问题：本次修改是否新增了测试用例？现有测试是否全部通过？
• 操作：
  • 在本地运行npm test或mvn test，确保 100% 通过。
  • 如果项目有覆盖率报告（如 Istanbul），检查新增代码的行覆盖率是否 ≥ 80%。
  • 最关键一步：运行git diff origin/main...HEAD -- '*.test.js'，确认新增的测试文件，是否真的覆盖了本次修改的核心逻辑分支。
• 为什么重要：一个没有测试的合并，就像在没有地图的情况下开车。你不知道哪里是悬崖。

检查四：CI 构建与部署模拟（CI Simulation）

• 问题：本地构建和部署流程，是否与 CI 完全一致？
• 操作：
  • 在本地，完全按照 CI 脚本的步骤，执行一次构建：

    # 例如，如果 CI 是：npm ci && npm run build && docker build -t myapp . # 那么你就必须执行完全相同的命令

  • 构建成功后，启动一个本地容器：docker run -p 3000:3000 myapp，用浏览器或curl访问，验证核心功能。
• 为什么重要：CI 环境和本地环境的细微差异（如 Node 版本、Docker 镜像 tag）是“本地好使，线上挂掉”的头号元凶。模拟 CI，就是消除这个差异。

这四道清单，平均耗时 5-8 分钟。但它把一个“点一下 Merge 按钮”的动作，变成了一个严谨的工程决策。我们团队实施后，因合并引入的线上 P0 故障下降了 73%。

4. 实操过程与核心环节实现：一次完整的“防坑”合并演练

4.1 场景设定：一个真实的、充满陷阱的 PR 合并

让我们把前面所有的理论，放进一个真实的、步步惊心的合并演练中。场景如下：

• 项目：一个基于 Express 的 Node.js API 服务。
• main分支：稳定运行，API 响应格式为{ code: 200, data: {...} }。
• feature/user-profile分支：由新同学 A 开发，目标是增加用户个人资料查询接口/api/v1/profile。
• hotfix/auth-token分支：由资深同学 B 开发，紧急修复了 JWT token 解析逻辑中的一个空指针异常。

A 同学的 PR 描述：“新增/api/v1/profile接口，返回用户基本信息。”
B 同学的 PR 描述：“修复authMiddleware.js中token.split('.')可能抛出TypeError的问题。”

两个 PR 都通过了各自的单元测试，CI 报告为绿色。现在，我们需要将它们合并到main。

4.2 步骤一：环境准备与基础配置加固

在开始任何合并操作前，先确保你的本地 Git 环境是“防坑”状态。

1. 设置强制非快进合并

# 进入项目根目录 cd /path/to/your/project # 为当前仓库设置 git config --local merge.ff false # 验证 git config --local merge.ff # 应输出 false

2. 启用 diff3 冲突风格

git config --local merge.conflictStyle diff3

3. 配置.gitattributes统一换行符在项目根目录创建.gitattributes文件：

# 设置所有文本文件使用 LF 换行符 * text=auto eol=lf # 明确指定某些文件为文本 *.js text *.json text *.md text *.yml text *.yaml text # 明确指定某些文件为二进制 *.png binary *.jpg binary *.pdf binary # 禁用 Git 对 lock 文件的换行符处理（避免 package-lock.json 被污染） package-lock.json -text yarn.lock -text

然后执行git add .gitattributes && git commit -m "chore: add .gitattributes for consistent line endings"。

实操心得：.gitattributes是团队协作的基石。它比core.autocrlf更精准、更可追溯。每次新成员加入，只需git clone，所有规则自动生效，无需额外配置。

4.3 步骤二：执行合并并深度分析过程

我们不直接git merge，而是分步执行，全程监控 Git 的内部状态。

1. 获取最新远程状态

git fetch origin # 确保你知道最新的 main 和两个 feature 分支的提交哈希 git log --oneline origin/main -n 3 git log --oneline origin/feature/user-profile -n 3 git log --oneline origin/hotfix/auth-token -n 3

2. 创建一个临时的“合并沙盒”分支

# 从最新的 main 创建 git checkout -b merge-sandbox origin/main

这一步至关重要。它让你在一个隔离的、可丢弃的环境中进行所有合并操作，避免污染你的工作分支。

3. 首先合并hotfix/auth-token

git merge --no-commit --no-ff origin/hotfix/auth-token # 此时，Git 会尝试合并，并可能产生冲突 # 查看冲突文件 git status # 如果有冲突，用 VS Code 打开（因为我们配置了 mergetool） git mergetool # 解决后，暂存 git add . # 然后，**不要立即提交**，先检查 git status # 确认所有文件已暂存 git diff --cached # 查看即将提交的合并内容

git diff --cached的输出是关键。它会显示hotfix分支的变更（authMiddleware.js的修复）是如何被整合进当前沙盒的。你需要确认：

• 修复的代码是否准确无误？
• 是否有其他无关的文件被意外修改？（比如，hotfix分支的开发者不小心改了README.md，这个修改不应该出现在这次合并中）

4. 接着合并feature/user-profile

git merge --no-commit --no-ff origin/feature/user-profile

这一次，Git 很可能报告冲突。让我们看看为什么。

假设hotfix/auth-token修改了middleware/authMiddleware.js，而feature/user-profile也修改了同一个文件（为了在新接口中复用认证中间件）。Git 会发现authMiddleware.js的同一区域被两个分支修改，于是报冲突。

此时，git mergetool会启动。在 VS Code 中，你会看到三个面板：

• LEFT (ours)：merge-sandbox当前状态（即刚合并完hotfix后的状态）。
• RIGHT (theirs)：feature/user-profile分支的authMiddleware.js。
• CENTER (base)：origin/main中的authMiddleware.js（merge base）。

关键操作：不要急于选择ours或theirs。先看base面板，理解这个函数最初的结构。再对比ours和theirs，理解hotfix修复了什么，feature又增加了什么。最终，你需要手写一个融合了两者优点的新版本，而不是简单地覆盖。

实操心得：我见过太多人，在mergetool中直接点“Accept Current Change”，结果把hotfix的修复给删了。记住，ours是“我们当前的”，theirs是“他们那边的”，而base是“我们共同的过去”。最好的解决方案，永远在base的基础上，融合ours和theirs的精华。

4.4 步骤三：合并后验证与“上线前”的终极检查

合并提交完成后，沙盒分支已经包含了两个 PR 的所有变更。现在，是时候进行终极验证了。

1. 运行全量测试套件

npm test # 如果有前端，还要跑前端测试 npm run test:client

重点观察：测试是否全部通过？失败的测试，是feature分支原有的问题，还是合并引入的新问题？查看失败测试的堆栈，定位到具体的文件和行号。

2. 启动本地服务，进行端到端（E2E）测试

# 根据你的项目，启动服务 npm run dev # 或者，如果使用 Docker docker-compose up --build

然后，用curl或 Postman 手动测试：

# 测试 hotfix 的修复：发送一个无效 token，应该返回 401，而不是 500 curl -H "Authorization: Bearer invalid-token" http://localhost:3000/api/v1/profile # 测试 feature 的新功能 curl http://localhost:3000/api/v1/profile

关键点：不仅要测试“能用”，更要测试“边界”。例如，给/api/v1/profile发送一个GET请求，再发送一个POST请求，看它是否正确地返回 405 Method Not Allowed。

3. 检查 API 响应格式一致性这是最容易被忽略的语义检查。main分支的响应是{ code: 200, data: {...} }，那么/api/v1/profile的响应，也必须遵循这个格式。打开浏览器的开发者工具，查看 Network 面板，确认响应体的 JSON 结构完全一致。如果feature分支的代码返回的是{ profile: {...} }，那么这就是一个严重的语义冲突，必须在合并前修正。

4. 生成并审查合并提交信息

git log -n 1 --pretty=%B

一个高质量的合并提交信息，应该包含：

• 第一行：简明扼要的标题，如Merge branches 'hotfix/auth-token' and 'feature/user-profile' into main。
• 空一行。
• 正文：详细说明本次合并带来的业务影响，例如：

  - 修复了 JWT token 解析时的空指针异常，提升了 API 稳定性。 - 新增了用户个人资料查询接口，为前端 V2 版本提供数据支持。 - 所有变更均已通过全量测试，E2E 验证通过。

注意：不要写“修复 bug”、“添加功能”这种空洞的描述。要写“修复了什么 bug”、“添加了什么功能”。这是给未来回溯问题的人看的。

4.5 步骤四：推送到远程并清理

当所有验证都通过后，就可以将沙盒分支推送到远程，完成合并。

# 将 merge-sandbox 分支推送到 origin/main git push origin merge-sandbox:main # 清理本地沙盒分支 git branch -d merge-sandbox # 清理远程的 feature 和 hotfix 分支（如果团队规范允许） git push origin --delete feature/user-profile git push origin --delete hotfix/auth-token

最后一步，也是最重要的一步：在团队的协作工具（如 Slack、钉钉）中，发送一条简洁的消息：

[DEPLOY] main 分支已更新，包含 hotfix/auth-token 和 feature/user-profile 的合并。 ✅ 全量测试通过 ✅ E2E 验证通过 ✅ API 响应格式一致性检查通过 预计今晚 22:00 进行灰度发布。

这条消息，就是你对这次合并行为的正式“签字画押”。

5. 常见问题与排查技巧实录：那些年我们踩过的坑

5.1 “明明没改，为什么 Git 说有冲突？”——关于空白字符与编码的战争

问题现象：
在git merge时，Git 报告src/utils/logger.js有冲突，但你用git diff查看，发现两个版本的文件内容看起来一模一样。

根本原因：

• 空白字符差异：一个分支使用了CRLF（Windows），另一个使用了LF（Unix）。Git 的core.autocrlf配置不当，导致在检出时自动转换，但在合并时又按原始字节比较。
• 不可见字符：UTF-8 BOM（Byte Order Mark）头。某些编辑器（如旧版 Notepad）会在文件开头插入EF BB BF三个字节，而 Git 会将其视为文件内容的一部分。
• 制表符 vs 空格：一个分支用 4 个空格缩进，另一个用 1 个制表符，虽然视觉效果相同，但字节