i、j、k未过时，但仅适用于作用域极小、逻辑极简、上下文自明的循环；否则应使用语义化变量名提升可读性。
为什么还在用 i、j、k？它们真过时了吗
没过时，但有明确适用边界：只在「作用域极小、逻辑极简、上下文自明」的循环里才推荐。比如三重嵌套遍历二维数组的索引，i/j 仍是清晰且被广泛理解的惯例；但一旦循环体超过 3 行、或涉及业务语义（如处理订单、学生、配置项），继续用 i 就等于主动放弃可读性。
- 常见错误现象：重构时发现
for(int i = 0; i ，但 <code>list实际是userList，而i在后续代码中又被误用于另一个集合，引发越界或逻辑错位 - 性能/兼容性无影响——命名纯属编译期符号，不改变字节码或运行时行为
- 现代 IDE（如 IntelliJ）对
i的自动补全和重命名支持很好，但对语义化变量名（如userId）的上下文感知更强，能更好辅助重构
for 循环中变量名该按什么规则选
核心原则是：变量名应反映它「代表什么」，而不是「怎么生成的」。索引是手段，不是目的。
- 遍历数组/列表索引 → 优先用
index（比i更直白），尤其当循环体里还涉及其他计算时：for (int index = 0; index PASS_THRESHOLD) { ... } } - 遍历集合元素 → 直接用元素单数名词：
for (String name : names)、for (Order order : orderList)，这是增强型for的天然优势 - 计数或累加用途 → 用
count、total、sum等动词性名称：int errorCount = 0; for (LogEntry entry : logs) { if (entry.isError()) errorCount++; } - 业务场景明确时 → 拆解出领域语义：
for (int studentId = 0; studentId 比 <code>for (int i = 0; i 多出 50% 的信息密度
哪些情况必须避免 i/j/k
不是语法错误，而是协作隐患。团队里只要有一人看不懂 j 在当前上下文里指代什么，这个变量名就失败了。
- 循环嵌套超过两层：三层以上时，
i/j/k容易混淆层级关系，改用row/col/cell或outerIndex/innerIndex更安全 - 循环变量参与业务逻辑计算：例如
if (i % 3 == 0) sendEmail(userList.get(i));—— 这里的i实际是用户序号，应为userIndex或直接用user配合indexOf() - 方法参数或字段级作用域：类字段命名为
private int i;是严重反模式，IDE 会警告，静态检查（如 SonarQube）直接标红 - 与常量/配置项同名冲突：比如已有
public static final int MAX_RETRY = 3;，再声明int maxRetry = 0;就容易误读，此时更不该用i
团队落地时最容易忽略的一点
很多人以为「统一用 i」是省事，其实真正省事的是「统一拒绝模糊命名」。一个项目里如果允许 i 出现在 Service 层循环里，就很难阻止它出现在 DTO 构造逻辑中——而那里往往藏着 N+1 查询或空指针隐患。
立即学习“Java免费学习笔记（深入）”；
最实际的做法：把 for (int i = 加入 CI 静态检查的告警规则（如 Checkstyle 的 VariableName 规则），仅对 test/ 和 benchmark/ 目录放行。这样既保住了传统习惯的容错空间，又卡住了业务代码的随意性。
