本文详解为何在“最多翻转 k 个 0 得到最长连续 1”问题中，用 `if` 替代 `while` 会掩盖逻辑缺陷，而正确解法必须使用 `while` 并配合 `math.max()` 更新答案。
在滑动窗口类问题中，窗口的合法性维护是核心——即确保窗口内满足约束条件（本题为：0 的个数 ≤ k）。初版代码中使用 while (current > k) 是正确且必要的，因为它能持续收缩左边界，直到窗口重新合法；而后续改用 if (current > k) 是表面通过测试、实则错误的权宜之计，它仅尝试收缩一次，无法应对 current - k > 1 的情况（例如 k=1 但窗口内有 3 个 0），导致窗口非法、长度计算失真。
关键错误不在循环类型本身，而在于答案更新逻辑的缺失。原 while 版本的问题是：
ans = right - left + 1; // ❌ 错误：每次迭代都直接赋值，未取最大值
这会导致 ans 被最后一次（可能非法或非最优）窗口长度覆盖。例如数组 [1,1,0,0,1,1,1,0,1]、k=2，当 right 到达末尾时，left 可能已滑动过远，right-left+1 反而小于历史最优解。
✅ 正确做法是：保留 while 进行充分收缩（保证 current <= k），再用 Math.max() 安全更新答案：
立即学习“Java免费学习笔记（深入）”；
for (int right = 0; right < nums.length; right++) {
if (nums[right] == 0) current++;
// ✅ while：确保窗口始终合法（可能收缩多次）
while (current > k) {
if (nums[left] == 0) current--;
left++;
}
// ✅ Math.max：记录所有合法窗口中的最大长度
ans = Math.max(ans, right - left + 1);
}⚠️ 为什么 if 版本能“通过部分测试”？
因为某些测试用例中，current 超出 k 的幅度恰好为 1（如 current == k+1），此时 if 收缩一次后恰好达标，结果偶然正确。但这属于巧合，无法泛化。一旦出现连续多个 0（如 k=1, 窗口含 [0,0,0]），if 只移出第一个 0，current 仍为 2 > k，窗口非法，后续计算全部失效。
? 总结：
- while 是滑动窗口收缩阶段的标准范式，用于彻底恢复约束；
- if 仅适用于“至多需调整一次”的特殊场景（如简单边界校正），不适用于约束容错型窗口；
- 答案更新必须基于合法窗口，且需用 Math.max() 持续追踪全局最优，而非直接赋值；
- 调试时应优先验证窗口不变量（current <= k 是否恒成立），再检查答案更新逻辑。
