写代码的时候，谁都遇到过那种让人头大的情况：翻出几个月前自己写的代码，看着函数里一堆变量和逻辑，愣是想不起来当初为啥这么写。这时候要是旁边有句注释，哪怕就一行，都能救命。
注释不是越多越好
有些人觉得注释写得越多越专业，其实不然。满屏都是 // 和 /**/，反而把重点淹没了。比如这段代码：
// 定义一个变量 a
int a = 1;
// 给 a 加 1
a = a + 1;这种注释纯属多余。变量叫 a 可能确实不清楚，但问题不在缺注释，而在变量命名太糊弄。改成 counter 或 retryCount，根本不需要解释它干嘛用的。
什么时候该写注释
真正需要注释的地方，是你“为什么”这么做，而不是“做了什么”。比如一段正则表达式：
// 匹配手机号，支持带区号、空格或短横线的格式
String phoneRegex = "^(\+86)?[\s-]?(1[3-9]\d{9})$";没人一眼能看懂这个正则的边界条件，加一句说明就省了别人反复推演的时间。
再比如你绕开某个框架的坑，用了不太直观的写法：
// 这里不能用自动提交，否则事务在 MySQL 5.7 下会提前释放锁
connection.setAutoCommit(false);这种业务逻辑之外的技术限制，不写清楚，后面接手的人很容易“优化”回坑里。
团队协作中的平衡
在公司里写代码，注释其实是沟通工具。新来的同事看不懂你的函数，要么是你写得太绕，要么是关键决策没留痕。但也不能指望靠注释救所有问题。如果一个函数长到需要十行注释才能讲明白，大概率是该拆了。
见过有人在一个 200 行的方法开头写半页文档，看起来很负责，实则是在给坏设计打补丁。与其花十分钟写注释，不如花十五分钟把它拆成五个小函数，名字起清楚，注释自然就少了。
好代码自己会说话
最理想的注释，是你根本不需要写。通过清晰的函数名、合理的结构、有意义的变量名，让代码自己表达意图。比如：
if (isExpired(item)) { ... }
// 比 if (item.updateTime < now - 30 * DAY) { ... } 直观多了但这话不能绝对化。现实项目总有例外，比如对接老系统、处理脏数据、满足奇怪的业务规则。这些地方，一句注释能省下后续无数会议。
实际建议
每次写完一段逻辑，停下来问自己：三个月后的我，能不能看懂这里的关键点？如果不能，补一句“为什么”。如果变量名、函数名已经足够说明“做什么”，那就别画蛇添足。
注释的量没有标准答案，但原则有：不解释代码显而易见的事，只说明背后的原因、权衡和上下文。就像路边的指示牌，不是越多越好，而是该出现的时候出现。”