Phorge 现代化改造实战（五）：替换 diff 子进程，兼容不等于逐字一致
内容提要
本文介绍Phorge现代化改造中，将diff计算模块迁入Gorge服务的过程。文章强调兼容性定义的重要性，指出unified diff需逐字节匹配GNU diff，而相同输入时需保留PHP历史行为。通过交叉验证发现8.6%差异源于歧义对齐，非实现错误。测试策略区分确定性格式与歧义场景，并讨论配置重构、算法优化等后续工作。
延伸解读
兼容性定义：逐字节一致还是语义一致？
文章强调，替换 diff 子进程时，兼容性并非简单的“输出相同”。对于 unified diff，下游解析器依赖精确的字节序列，因此必须与 GNU diff 逐字节一致；而对于相同输入，则需保留 PHP 历史行为，即使它与 GNU 不同。这种区分避免了盲目追求“100% 一致”，而是根据消费者需求定义兼容边界。
8.6% 差异的启示：量化风险而非急于修复
交叉验证发现约 8.6% 的差异，但进一步分析显示，这些差异主要源于歧义对齐，而非实现错误。文章建议先量化影响，再决定是否修复。这提醒我们，在迁移中遇到不一致时，应区分“必须修复的错误”与“可接受的偏差”，避免为追求完美而引入不必要的复杂度。
测试策略：区分确定性格式与歧义场景
文章提出，对于确定性格式（如 hunk 头），应要求与系统 diff 逐字节一致；而对于存在多个合法对齐的歧义场景，则只验证 hunk 头和编辑数量。这种分层测试策略既保证了关键不变量，又避免了因算法选择差异导致的误报，使测试更稳定、更有意义。
配置重构与算法优化：留待后续的清晰边界
文章指出，当前配置加载方式在模块增多时会变得别扭，但为避免扩大改动风险，将其列为后续项。同样，LCS 算法导致的内存限制和对齐差异，计划通过引入 Myers 算法一并解决。这种“先完成迁移，再优化”的思路，体现了对风险控制和渐进式改造的重视。
Q&A
Phorge现代化改造中，diff模块迁移到Gorge服务的主要目标是什么？
主要目标是将代码评审链路中边界清楚的计算环节（diff计算）从PHP应用中抽离出来，迁入Gorge服务，由Go实现，以降低对子进程的依赖，并保持与原有行为的兼容。
在diff模块迁移中，兼容性定义为什么重要？
因为diff输出不仅是给人阅读的文本，更是下游解析器的输入协议。如果输出格式（如hunk头、行号）出现偏差，可能导致前端展示错误或评论位置错位。因此需要明确兼容的精确程度：unified diff需逐字节匹配GNU diff，而相同输入时需保留PHP历史行为。
Gorge的diff模块如何处理相同输入的情况？
当两个输入完全相同时，GNU diff不输出任何内容，但Phorge原PHP代码会合成一份“没有发生变化的diff”，包含类似'@@ -1,1 +1,1 @@'的hunk。Gorge的diff模块保留了这一历史行为，而不是采用GNU的空白输出。
在diff模块的交叉验证中，8.6%的差异是如何归因的？
通过进一步分析，8.6%的字节差异中，hunk头不一致占0.1%，编辑数量不一致占0.2%，而8.3%的差异源于歧义对齐，即当存在多个最小对齐时，GNU的Myers算法与当前LCS回溯选择了不同的答案。这些差异并非实现错误，而是算法选择不同。
Gorge的diff模块测试策略是什么？
测试分为两组：第一组穷举行数与尾换行状态的组合，要求与系统diff逐字节相同；第二组刻意制造歧义场景，只要求hunk头和编辑数量相同，字节一致率仅记录日志。此外，还使用系统diff进行交叉验证，并区分退出码1（正常差异）和退出码2（错误）。
为什么Gorge将diff模块并入现有的gorge-render服务，而不是单独部署？
因为diff与render具有相同的运行特征：无状态、计算密集、不依赖外部系统，且流量和资源曲线相似。合并可以避免多一套构建、部署和运维对象，而不会牺牲故障隔离。当模块开始依赖外部系统或资源曲线分叉时，才考虑拆分。
在diff模块迁移中，如何处理行尾换行符的差异？
实现中的行模型必须同时保存文本和终止状态（是否有换行符），两个字段都参与相等判断。否则，给文件补一个尾换行这样的真实变更会被错误地吞掉。
Gorge的diff模块后续有哪些优化计划？
后续计划包括：将config.Base的加载提升到进程层，避免模块依赖render的配置；将LCS算法替换为Myers算法，以降低内存占用并收窄与GNU在歧义场景的差异；以及让架构分层守卫自动发现internal/下的模块，而不是依赖人工维护禁止列表。
