文本对比入门：LCS 与 diff 输出读法

Every code review leans on a diff, yet the algorithm behind those red and green lines stays a mystery to most. It is one elegant idea — and knowing it helps you read imperfect diffs correctly.

The longest common subsequence

A diff splits both texts into lines and finds the longest common subsequence — the biggest chain of identical lines that appear in the same order. Everything else is marked added or removed. That is why moved paragraphs can show as delete-plus-add instead of a move: pure LCS does not model motion.

Line diff, then character polish

Line-level diffing stays fast even for thousands of lines. Good tools add a second pass: inside changed line pairs, highlight the exact character or word that changed. The Text Diff Checker shows both — block alignment plus character detail — entirely in your browser.

Formatting noise vs real changes

Indentation differences, capitalization and line-ending styles (CRLF vs LF) bury real edits. That is what the ignore-whitespace and ignore-case options exist for: they change what equality means before the LCS runs, so the diff reports content changes, not formatting churn.

Workflow beyond git

• Compare JSON responses before and after an API change — run both through the JSON Formatter first, then the diff aligns semantically instead of by incidental formatting.
• Review config or policy files copied between environments.
• Clean repeated lines in the inputs first with the Deduplicator so the diff reports real edits, not duplicates.

Because comparison is local, confidential documents and credentials are safe to run through the diff tool — nothing uploads anywhere.