编辑距离计算必须先将文件安全读入内存字符串，再用空间优化的动态规划实现；关键在于二进制模式读取以保字节一致，并按需处理UTF-8字符语义。
用 std::string 读取文件后调用动态规划实现编辑距离
直接对磁盘上的二进制流做编辑距离没意义，必须先加载为内存中的字符串序列。C++ 标准库不提供现成的文件级编辑距离函数，得自己读、自己算。关键不是“怎么调用”，而是“怎么读得安全”和“怎么算得准”。
常见错误是用 std::getline 逐行读但丢掉换行符，导致两文件行数相同但内容错位；或者用 std::ifstream::rdbuf() 一次性读入却忽略 Windows 换行符 \r\n 在长度统计中多算一个字符。
- 统一用
std::ifstream配合std::stringstream或std::string构造函数读全内容，保留所有空白符（包括\n和\r） - 若业务上需忽略换行差异（比如比对逻辑内容而非格式），提前用
std::replace把\r\n和\r全转成\n，再把连续\n归一化——但这属于业务逻辑，不是编辑距离本义 - 编辑距离定义本身包含插入/删除/替换操作单位是「字符」，所以 UTF-8 文件要小心：一个汉字占 3 字节，但应视为 1 个字符；若真需 Unicode 意义上的编辑距离，得先用 ICU 或
utf8cpp库解码为std::u32string
levenshtein_distance 函数要避免 O(m×n) 空间爆炸
教科书版二维 DP 表空间复杂度是 O(m * n)，两个 100KB 的文件转成字符串后约 10⁵ 字符，DP 表就要 10¹⁰ 个 int，超内存。必须降维。
实际只需保存两行：当前行和上一行。用两个 std::vector<int></int> 轮换即可，空间压到 O(min(m, n))。别手滑写成三个 vector 或反复 resize——那会触发多次堆分配，比空间浪费更慢。
立即学习“C++免费学习笔记（深入）”；
- 先确保
s1.size() ，让短串做“行”，长串做“列”，减少内层循环次数 - 初始化第一行用
i（即插入 i 个字符），第一列用j（即删除 j 个字符） - 核心递推式：
dp[j] = min({dp[j-1] + 1, prev[j] + 1, prev[j-1] + (s1[i-1] != s2[j-1])})，注意prev是上一轮的完整行，dp是当前行 - 边界情况：任一字符串为空时，距离就是另一字符串长度，可提前返回
处理大文件时别把整个文件读进 std::string
当文件超过几十 MB，std::string 一次性加载会卡顿甚至失败。编辑距离本质是序列比对，而纯文本的编辑距离在局部有强相关性——可以分块近似，但要注意这不是严格解。
严格做法只有两种：一是改用内存映射（mmap on Linux / CreateFileMapping on Windows），然后分段读入 char* 再转 std::string_view 计算；二是流式读取+滚动窗口，但编辑距离无法真正流式计算，因为替换操作依赖前后文。
- 如果只是判断“是否相似”，可用
simhash或minhash预筛，再对候选对精确计算——这在批量比对场景很实用 - 若必须精确且文件极大（如 >500MB），考虑用外部排序思路：把文件按行切片，每片单独计算与基准片的编辑距离，最后加权聚合；但这已偏离原始问题，属于工程妥协
- 别用
std::fstream::seekg随机跳转读字符——ASCII 下可行，UTF-8 下跳到中间字节会解码失败
Windows 下打开文件记得用 std::ios::binary
默认文本模式在 Windows 会把 \r\n 自动转成单个 \n，导致读出的 std::string 长度比实际文件字节数少，编辑距离结果偏小。Linux/macOS 文本模式无此问题，但跨平台代码必须显式声明。
错误写法：std::ifstream f("a.txt");；正确写法：std::ifstream f("a.txt", std::ios::binary);。之后用 f.read() 或 std::string((std::istreambuf_iterator<char>(f)), {})</char> 读取，才能保证字节一一对应。
- 即使你只关心逻辑内容，也应先以 binary 模式读入，再由你自己决定是否 normalize 换行符——控制权在代码手里，不在系统运行时
- 用
std::filesystem::file_size验证读入长度是否匹配，调试时能立刻发现换行符被吞的问题 - 别依赖
f.gcount()判断读取是否完整——它只反映最后一次read的字节数，对string构造方式无效
编辑距离的“字符”单位在 C++ 里默认是 char，这是最常被忽略的前提。你传进去的是字节序列，不是语义字符。真要支持中文、emoji，就得在读文件后做 UTF-8 解码，而这一步没有标准库函数兜底。
