命名不是小事，别再用 user1、tempData 了
刚接手一个老项目时，打开文件看到一堆 getSomething()、handleData() 这种函数名，真让人头大。你不知道它到底干了啥，只能一行行往下读。服务端代码动不动几千行，命名模糊等于埋雷。变量和函数名得清楚表达意图，比如 getUserById 比 getData 强十倍，别人一眼就知道这是按 ID 查用户。
类名也一样，别图省事叫 Utils 或 Tools，这种名字就像垃圾桶，啥都往里扔。如果是一堆日期处理方法，就叫 DateHelper；如果是发邮件相关的，直接叫 MailService，谁看了都明白。
接口返回要统一，别让前端猜数据结构
有次上线出问题，前端说接口返回的字段突然变成 null，但文档没改。查了一圈才发现后端在异常时直接返回空对象，正常时却套了一层 data。这种不一致让调用方很难受。建议所有接口返回统一格式：
{
"code": 0,
"message": "success",
"data": {
"id": 123,
"name": "zhangsan"
}
}哪怕没数据，也保持结构不变，前端处理起来省心，不容易崩溃。
错误处理别忽略，日志要能定位问题
线上服务最怕出错找不到原因。有人写代码 catch 了异常就打印个 error occurred 完事，这等于没打。记录日志得带上关键上下文，比如用户 ID、请求路径、输入参数。最好还能生成唯一 traceId，方便追踪整个调用链。
另外，别把数据库密码、密钥这些敏感信息写在代码里。曾经有个同事把配置明文提交到 Git，半夜被叫起来处理数据泄露风险。该用环境变量就用环境变量，别偷懒。
接口别太“胖”，一个函数只干一件事
见过一个函数写了两百多行，从参数校验、写数据库、发消息队列到通知第三方全包了。这种代码改一处就得测全部，一动就容易崩。函数应该尽量单一职责，比如校验归校验，存储归存储。拆开之后不仅好测试，复用性也高。
比如用户注册流程，可以拆成 validateRegisterForm、createUserRecord、sendWelcomeEmail 几个独立步骤，每个步骤出问题都能单独处理，逻辑清晰。
代码格式靠工具，别靠人眼盯
团队里有人喜欢用四个空格，有人坚持两个空格，还有人用 Tab。风格不统一看着就累。与其争论，不如直接上 ESLint、Prettier 这类工具，提交代码前自动格式化。配置一次，全员遵守，省下无数口水战。
同样的，API 文档也别靠手写。用 Swagger 或 OpenAPI 自动生成，接口变了文档自动更新，前端不用再问“这个字段到底有没有”。