continue不能简单替换成if包裹后续逻辑，因其会直接跳转至循环条件判断（如i++后重新判断i），而if仅控制执行分支，无法复现continue的跳转语义。
continue 不能简单替换成 if 包裹后续逻辑
很多人以为 continue 就是“跳过本轮循环体剩下的代码”，所以尝试用 if 把后续语句包起来实现等价效果。这在单层、无嵌套、无副作用的场景下看似可行，但实际极易出错。
常见错误现象：continue 会直接跳转到循环条件判断（比如 i++ 执行后重新判断 i ），而 <code>if 块只是控制执行路径，不会改变循环变量更新节奏或跳过迭代器推进逻辑。
- 如果循环体里有
i++写在continue前面，改用if后容易漏掉该自增，导致死循环 - 使用
for-each时，continue跳的是下一次迭代；手动用if包裹，根本没法模拟“跳过当前元素、取下一个”的行为 - 嵌套循环中，
continue默认只作用于最近一层；用if模拟时，缩进和逻辑边界极易混乱
for (int i = 0; i
continue 在传统 for 循环里不是“跳到循环开头”，而是“跳到 for 语句的 update 表达式（第三部分）执行，再重新判断 condition（第二部分）”。这是关键，也是最容易被忽略的语义细节。
示例对比：
立即学习“Java免费学习笔记（深入）”；
for (int i = 0; i < 5; i++) {
if (i == 2) continue;
System.out.println(i);
}
输出是 0、1、3、4 —— 注意：当 i == 2 时，i++ 仍会执行（变成 3），然后重新判断 i ，接着进入下一轮。
- 如果你写成
if (i != 2) { System.out.println(i); }，看起来一样，但前提是i++必须放在if外面且位置固定 - 一旦把
i++错误地塞进if块里，比如if (i != 2) { System.out.println(i); i++; }，那i == 2时i就卡住不动了 - 更隐蔽的问题：如果循环体里还有其他变量要更新（比如累加器、状态标记），
continue会跳过它们；而if包裹必须显式排除所有被跳逻辑，漏一个就逻辑错位
哪些情况真能安全替换？看有没有“可提取的公共后置逻辑”
只有当循环体结构清晰、且所有“非跳过路径”都共享同一段收尾操作时，才可能把 continue 拆成 if + 提前 return 或反向条件包裹。
适用场景举例：批量处理对象，过滤后统一做日志或提交
for (String s : list) {
if (s == null || s.trim().isEmpty()) continue;
process(s);
logSuccess(s); // 这行是所有有效项都要执行的
}
可以改为：
for (String s : list) {
if (s != null && !s.trim().isEmpty()) {
process(s);
logSuccess(s);
}
}
- 前提是
process()和logSuccess()确实只应在过滤通过后调用 - 如果中间还有像
counter++或cache.put(s)这类必须每次循环都执行的逻辑，就不能简单包裹——得拆成两块：前置必执行部分 + 后置条件执行部分 - Java 8+ 更推荐用
list.stream().filter(...).forEach(...)，语义更明确，也天然规避了continue位置争议
增强 for 循环（for-each）里 continue 的特殊性
在 for (Type item : collection) 中，continue 的含义更“纯粹”：它就是终止本次迭代，由 JVM/编译器自动取下一个元素。你无法手动模拟这个行为，因为没有暴露迭代器或索引。
试图用 if 替代只会让你写出脆弱代码：
- 如果集合是
ArrayList，有人会想用索引遍历再加if判断——但这已经不是 for-each 了，且破坏了抽象 - 如果集合是
LinkedList或自定义Iterable，手动索引访问可能 O(n) 遍历，性能崩塌 - 并发修改时，
for-each抛ConcurrentModificationException是明确信号；而手写索引循环若没加锁，问题更隐蔽
真正该做的，是接受 continue 在这里不可替代的事实——它不是语法糖，是迭代协议的一部分。
复杂点在于：很多人把 for-each 当作“简化版 for”，却忽略了它背后是 Iterator 接口。跳过一项，本质是调一次 iterator.next()，这个动作没法用普通分支逻辑重写。
