多人协作开发一个前端项目时，HTML文件的合并冲突几乎是绕不开的问题。页面结构文件通常由多人共同维护，导航栏加个入口、表单区改个布局，两个人在同一个区块动手，一合并就冲突了。HTML的特殊之处在于标签层层嵌套，冲突区域如果不仔细看，很容易把结构改坏，导致页面渲染直接乱掉。这篇文章就来详细讲讲遇到HTML合并冲突时的完整处理流程。
一、HTML合并冲突是怎么产生的
要解决冲突，得先明白Git为什么会标记冲突。Git在合并分支时，会逐行对比两个分支对同一文件的修改。如果两个分支修改的是同一个文件的不同区域，Git可以自动合并；但如果修改发生在相同或相邻的行，Git无法判断该保留哪一方，就会把冲突标记写入文件，交给开发者手动处理。
HTML文件特别容易触发冲突，原因有几个：第一，HTML的结构是强嵌套的，一个区块的改动往往涉及开标签和闭标签两处，改动行数多，撞车概率大；第二，团队常按页面区块分工，但区块边界并不总是清晰，两个人都往同一个<div>里塞内容是常有的事；第三，格式化工具如果配置不一致，一个人保存时自动换行，另一个人没换，整段代码都会被标记成冲突。
典型的冲突标记长这样：
<div class="header">
<<<<<<< HEAD
<nav><a href="/home">首页</a><a href="/news">新闻</a></nav>
=======
<nav><a href="/home">首页</a><a href="/about">关于我们</a></nav>
>>>>>>> feature/nav-update
</div>其中<<<<<<<到=======之间是当前分支的代码，=======到>>>>>>>之间是待合并分支的代码。理解这个结构是解决冲突的第一步。
二、解决冲突的完整操作步骤
下面以一个实际场景演示：你在feature分支上改了导航，同事在develop分支上也改了导航，现在要把feature合并进develop。
第一步，执行合并命令并确认冲突状态：
git checkout develop git pull origin develop git merge feature/nav-update # 输出提示：CONFLICT (content): Merge conflict in index.html git status # 查看哪些文件处于冲突状态
git status会列出所有冲突文件，同时Git会在这些文件中插入冲突标记。此时不要慌，逐个文件处理即可。
第二步，打开冲突文件，定位所有冲突块。建议在编辑器中搜索<<<<<<<，确保没有遗漏。VS Code会在冲突区域显示彩色高亮和“采用当前更改”“采用传入的更改”等快捷按钮，但要提醒一句，HTML冲突不建议直接点按钮盲选，因为很可能是两边改动都要保留一部分。
第三步，逐个冲突块分析并手工编辑。这一步是核心，你需要搞清楚三个问题：对方改了什么，我改了什么，业务上正确的最终形态是什么。比如上面的例子，可能正确结果是两个链接都要：
<div class="header">
<nav>
<a href="/home">首页</a>
<a href="/news">新闻</a>
<a href="/about">关于我们</a>
</nav>
</div>编辑完成后，务必删除所有冲突标记行，包括<<<<<<<、=======和>>>>>>>这三行，任何一个残留都会直接出现在页面上，还会破坏HTML结构。
第四步，检查标签闭合是否完整。HTML冲突最大的隐患就是标签错配，比如你保留了对方的开标签却删掉了对应的闭标签。可以利用编辑器的格式化功能快速验证：如果格式化后缩进错乱，多半是结构坏了。也可以借助npx html-validate index.html这类工具做语法校验。
第五步，本地验证后提交。在浏览器中打开页面确认渲染正常、交互功能没有受影响，然后完成合并：
git add index.html git commit -m "merge feature/nav-update, 解决导航区域冲突" git push origin develop
三、merge与rebase处理冲突的区别
除了直接merge，很多人也会用rebase保持提交历史整洁，两者在冲突处理上体验不同。merge是把冲突一次性全部暴露出来，你处理完所有冲突做一次提交，历史里会留下一个合并节点；rebase则是把你分支上的提交逐个重放到目标分支上，可能一个提交就触发一次冲突，需要反复解决。
rebase处理冲突的流程是这样的：
git checkout feature/nav-update git rebase develop # 解决冲突后 git add index.html git rebase --continue # 如果实在搞砸了，可以用下面的命令回到rebase之前 git rebase --abort
经验之谈：如果是长期并行开发的功能分支，用merge更稳妥；如果是个人开发完准备合入主干，先rebase再合并能让历史更干净。另外切记，已经被推送到远端、其他人可能基于它开发的分支，不要执行rebase，否则会给团队带来更大的混乱。
四、如何减少HTML冲突的发生
解决冲突固然重要，但更聪明的做法是减少冲突。首先是拆分文件，一个几千行的HTML巨型页面几乎是冲突制造机，能拆成模板组件就拆，每个人只负责自己的组件文件，冲突自然就少了。
其次是统一格式化规范。团队统一使用Prettier并提交一致的配置文件.prettierrc，配合husky在提交时自动格式化，避免因换行、缩进差异产生的伪冲突。这类冲突最冤枉，双方代码逻辑一模一样，只是格式不同。
最后是勤拉勤推。小步提交、频繁同步主干代码，每次合并的改动量小，即使冲突了也容易处理。相反，一个分支憋两周再合并，冲突块又多又复杂，解决起来事倍功半。配合上面这些方法，团队协作中的HTML冲突就能控制在可管理的范围内。