小王刚入职第三天，就被组长叫去改一段“别人写的代码”。打开文件，满屏都是英文变量名和没头没尾的函数调用，唯一能看懂的，是顶部那行注释：// 这里处理数据。他盯着看了五分钟，还是没搞清“这里”是哪，“数据”从哪来、往哪去。
注释不是写日记，是写说明书
很多人以为注释就是“把代码翻译成中文”，其实不对。真正有用的注释，回答的是三个问题：为什么这么写？它在干啥？有什么坑要注意？而不是“if 判断是否为真”。这种废话式注释，比不写还糟——它占地方、骗信任、还容易过时。
几条接地气的注释习惯
1. 函数开头写清楚“意图”，不是“动作”
别写：// 计算用户积分
试试：// 返回用户当前可兑换的积分（不含冻结部分，已扣除昨日签到奖励）
2. 复杂逻辑块前加短注释，一行就够
比如这段处理时间偏移的代码：
// 注意：服务端时间比本地快8小时，需先转为UTC再比较比直接扔一堆 new Date().getTime() - 8 * 60 * 60 * 1000 强十倍。
3. 魔数必须有解释
看到 if (status === 4)，没人知道 4 是“审核中”还是“已作废”。改成：
// 4 = 审核中（后端文档 v2.3 约定）4. 别在代码行末写注释
像这样：const timeout = 3000; // 单位毫秒 —— 行末注释难维护、易错位、合并冲突时还容易丢。统一提到变量上方更清爽。
什么情况根本不用注释？
变量名能说清的，就别画蛇添足。比如：const isUserLoggedIn = true;，再加个 // 判断用户是否已登录 就是纯属浪费屏幕空间。同理，for (let i = 0; i < list.length; i++) 后面跟个 // 遍历数组，等于没说。
注释真正的价值，是在代码“看起来合理但实际有特殊考虑”的地方。比如：// 此处不用 fetch 而用 XMLHttpRequest，因需兼容 IE11 的超时重试机制——这句话，救过多少人两小时调试时间。
写注释不是交作业，是给三个月后的自己、或者隔壁工位正抓耳挠腮的同事，留一条能顺着走的路。