确定循环次数用for，不确定用while：for适用于可预知次数的遍历或计数，while适用于依赖状态变化的场景；for变量作用域受限更安全，while变量可后续复用；for-each适合纯遍历，需索引或修改集合时应回退传统for或使用迭代器。
知道循环次数就用 for，不确定就用 while
这是最直接的判断依据。比如遍历长度为 list.size() 的 List、打印 1 到 100 的数字、处理固定长度的数组——这些都能“数得清”，for 是天然匹配：初始化、条件、更新全写在一行，不易漏掉 i++，变量 i 作用域也干净（出循环即失效）。
而像“读取用户输入直到输入 "quit"”“等待网络响应成功”“重试登录最多 3 次但可能提前成功”——这些你无法预知执行轮数，只靠某个状态变化来决定是否继续，while 更自然。它不承诺执行次数，只守一个条件门禁。
- 误用
for实现状态驱动逻辑 → 容易把退出条件硬塞进循环头，导致逻辑扭曲或边界错位 - 误用
while实现固定次数循环 → 初始化和更新分散，易漏i++或写成i <= n导致多跑一次
for 循环变量出不了括号，while 变量能被后续代码访问
这不只是语法细节，而是影响可维护性的实际约束。for (int i = 0; i < 5; i++) 中的 i 在循环结束后不可见；而 int i = 0; while (i < 5) { ... i++; } 的 i 仍存活，可能被意外复用、覆盖或引发命名冲突。
- 需要循环后继续用计数器（比如记录最终执行了多少次）→ 选
while或提前声明int count = 0 - 纯遍历且无需索引 → 优先考虑
for-each（for (String s : list)），比传统for更安全、更简洁 - 需要反向遍历或跳步（如每次 +2）→ 传统
for更直观，while也能做但要手动管理步长
别在 for-each 里修改集合，也别指望它给你下标
for (String s : list) 看似简单，但它底层调用 Iterator，一旦你在循环体中调用 list.remove(s) 或 list.add(...)，立刻抛 ConcurrentModificationException。它也不暴露当前索引——想删第 3 个元素？想按位置替换？它帮不上忙。
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
立即学习“Java免费学习笔记（深入）”；
- 要边遍历边删 → 用显式
Iterator：Iterator<String> it = list.iterator(); while (it.hasNext()) { if (needRemove) it.remove(); } - 需要下标或随机访问 → 回退到传统
for (int i = 0; i < list.size(); i++)，尤其对ArrayList安全高效；但对LinkedList避免用get(i)，改用for-each或迭代器 - 想“执行完一次再问要不要继续” → 不是
for或while的场景，该用do-while，比如命令行菜单、密码重试
死循环往往不是写错了，而是选错了结构
真正卡住程序的，常不是语法错误，而是模型错配。比如用 while ((line = reader.readLine()) != null) 读文件没问题，但若换成 for 就必须手动模拟流式判断，极易写出 for (; reader.readLine() != null; ) 这种每次读两行、漏数据还难调试的代码。
-
while条件一开始为false→ 循环体一次都不执行（合理行为，不是 bug） -
do-while条件一开始为false→ 循环体仍会执行一次（适合“先加载资源，再检查是否有效”） - 所有循环都依赖“状态推进”，漏掉
i++、reader.readLine()、attempts++等更新动作 → 100% 死循环，和语法无关，和逻辑完整性有关
复杂点在于：真实业务里往往混合了“固定次数”和“状态驱动”的特征。比如“最多重试 5 次，但只要成功就立刻退出”。这时别硬套单一结构——用 while 控制状态，内部用计数器配合 break，比强行塞进 for 更清晰、更易测试。
