最稳方案是用std::vector存两份行序列并双指针扫描：先统一getline读取、trim预处理，再通过容忍窗口（如3行）判断增删改，避免误用std::mismatch；输出应直白标注del/add行号及内容，行号从1起始。
用 std::vector 存两份行序列再双指针扫描最稳
直接读文件到内存逐行比对，不依赖外部库，是 C++ 里最可控、最容易调试的方案。核心不是追求“像 diff”，而是先做到「能准确标出增删行位置」——diff 的启发式合并、最小编辑距离那些属于进阶优化，初版反而容易因过度设计出错。
常见错误现象：std::getline 读完最后一行没换行符时漏掉内容；空行或含 \r\n 的 Windows 文件导致行尾不一致；用 == 比较带空格缩进的行却忽略前后空白差异。
- 按行读取时统一用
std::getline(file, line)，别用operator>>（会跳过空行） - 存行用
std::vector<:string></:string>，别用std::list或std::deque（随机访问慢，双指针需要 O(1) 索引） - 如果要忽略空白差异，提前对每行做
trim（自己写个简单函数，别用boost::algorithm::trim增加依赖）
std::mismatch 和 std::equal 只适合「找第一处不同」，不适合整份比对
这两个算法常被误用：它们返回首个不匹配位置，但无法告诉你「A 多了三行，B 少了两行，中间还有一行内容改了」——这正是 diff 类工具的核心输出需求。强行套用只会让你在循环里反复调 std::mismatch，逻辑混乱且难 debug。
使用场景：只适合预检，比如「快速判断两个配置文件是否完全一致」；或者作为双指针扫描中的辅助判断（比如某段连续相同行的长度）。
- 别用
std::mismatch驱动主流程，它不维护上下文状态 - 若真要用，注意它返回的是
std::pair<it1 it2></it1>，不是索引，别直接减begin()算行号（迭代器差值可能非 O(1)） - 比较前确认两容器 size 是否相等——
std::equal对不等长容器行为未定义（实际通常返回 false，但不保证）
双指针扫描时怎么处理「插入」和「删除」的交叉判断
这是最容易卡住的地方：当 A 文件第 5 行消失、第 6 行变成新内容，B 文件多了第 5a 行，人眼一看是「删一行 + 插一行 + 改一行」，但程序得靠局部窗口决策。关键不是一步到位还原 git diff 的 hunk，而是让输出至少不自相矛盾。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
参数差异：你得定一个「容忍窗口」，比如最多允许连续 3 行不匹配才认为发生插入/删除；太大则漏判，太小则把真实修改当成增删。
- 用两个索引
i（A）、j（B），初始都为 0 - 相等就同时 ++；不等时，检查
A[i]是否在B[j+1..j+3]出现 → 判为 A 删除；检查B[j]是否在A[i+1..i+3]出现 → 判为 B 插入 - 一旦触发插入或删除，必须推进对应指针，并标记该行类型（
DEL/ADD），不能回退重试 - 性能影响：窗口设为 3 是经验平衡点；设成 10 会让最坏情况复杂度升到 O(n²)，尤其大文件
输出格式别硬啃 POSIX diff 标准，先用 std::cout 打印带行号的标记就行
很多人一上来就想输出 3c3 或 5,7d4 这种格式，结果卡在解析规则上。其实业务中真正需要的，是「哪几行变了、怎么变的」，不是兼容 patch 工具。
可给出简短示例：
--- file_a.txt +++ file_b.txt @@ -2,3 +2,4 @@ line2 -line3 +line3-new line4 +line5-added
但实现时先输出这种更直白的：
DEL 3: "line3" ADD 3: "line3-new" ADD 5: "line5-added"
- 行号从 1 开始计数，别用 0-based（所有人看 diff 都默认 1-based）
- 别在输出里拼接原始文件路径——路径由调用者传入，比对逻辑只管内容
- 如果后续要对接 patch，再单独写个格式转换函数，别混在比对主逻辑里
真正的复杂点不在算法本身，而在于「如何定义两行『实质相同』」：是全字符相等？忽略空格？忽略注释？这些语义判断必须外置、可插拔，不能写死在双指针循环里。否则改个需求就得重翻整个比对函数。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
