如何通过后端开发场景实战提升项目开发效率?
摘要:Node.jsJavaGo后端项目的AGENTS.md怎么写 承上启下 前端篇写完了,这篇来说说后端项目怎么整。和前端不一样,后端更关注数据处理、业务逻辑、接口设计这些事。不同的后端技术栈,差别还挺大的。我分别说说我用过的几种主流方案。
Node.js/Java/Go后端项目的AGENTS.md怎么写
承上启下
前端篇写完了,这篇来说说后端项目怎么整。和前端不一样,后端更关注数据处理、业务逻辑、接口设计这些事。不同的后端技术栈,差别还挺大的。我分别说说我用过的几种主流方案。
Node.js/Express 项目
Node.js 后端最常用的是 Express 或者 NestJS。我先说 Express,因为简单嘛,大家都懂。
# AGENTS.md - Node.js REST API 项目
## 项目概述
Express.js RESTful API 服务,提供用户管理、商品订单等功能。
## 技术栈
- Node.js 18+
- Express.js
- TypeScript
- PostgreSQL + Prisma
- Jest + Supertest
- JWT 认证
## 开发环境
### 安装依赖
```bash
npm install
启动开发服务器
npm run dev # 支持热重载
运行测试
npm test # 单元测试
npm run test:integration # 集成测试
代码检查
npm run lint
npm run typecheck
数据库
npm run db:migrate # 数据库迁移
npm run db:seed # 种子数据
npm run db:studio # Prisma Studio
项目结构
src/
├── controllers/ # 控制器层
├── services/ # 业务逻辑层
├── repositories/ # 数据访问层
├── models/ # 数据模型
├── middleware/ # 中间件
├── routes/ # 路由定义
├── utils/ # 工具函数
└── types/ # 类型定义
API 规范
RESTful 设计原则
使用标准 HTTP 方法(GET/POST/PUT/DELETE)
资源命名使用复数形式(如 /users, /orders)
路径参数使用冒号(如 /users/:id)
响应格式
// 成功响应
{
"data": { ... },
"meta": { "page": 1, "total": 100 }
}
// 错误响应
{
"error": {
"code": "VALIDATION_ERROR",
"message": "请求参数验证失败",
"details": [...]
}
}
状态码使用
200: 成功
201: 创建成功
400: 请求参数错误
401: 未认证
403: 无权限
404: 资源不存在
500: 服务器错误
代码规范
控制器规范
只做请求解析和响应格式化
不包含业务逻辑
使用 async/await 处理异步
服务层规范
包含所有业务逻辑
使用事务保证数据一致性
错误抛出自定义异常
数据访问层规范
只做数据库操作
不包含业务逻辑
使用 Prisma Transaction
日志规范
禁止使用 console.log
使用 pino 日志库
区分日志级别(info/warn/error)
包含请求 ID 方便追踪
测试要求
测试分层
控制器层:请求/响应测试
服务层:单元测试(mock 依赖)
集成测试:使用测试数据库
测试覆盖率
目标:80% 以上
提交前必须通过所有测试
安全约束
禁止硬编码密钥和凭证
敏感配置使用环境变量
密码必须使用 bcrypt 哈希存储
所有接口实现速率限制
CORS 配置白名单域名
注意事项
中间件顺序:先认证,后业务
数据库连接使用连接池
大数据量使用分页
敏感操作记录日志
## NestJS 项目
NestJS 现在很火,它是基于依赖注入的企业级框架,写法和原生 Express 不太一样。
```markdown
# AGENTS.md - NestJS 微服务项目
## 技术栈
- Node.js 18+
- NestJS 10
- TypeScript
- TypeORM / Prisma
- PostgreSQL
- JWT + Passport
- WebSocket (Socket.io)
## 开发命令
```bash
npm install
npm run start:dev # 开发模式
npm run build # 生产构建
npm run test # 单元测试
npm run test:cov # 带覆盖率
npm run lint
项目结构(NestJS 特色)
src/
├── modules/ # 功能模块
│ ├── users/
│ │ ├── dto/ # 数据传输对象
│ │ ├── entities/ # 实体
│ │ ├── users.controller.ts
│ │ ├── users.service.ts
│ │ └── users.module.ts
├── common/ # 公共模块
│ ├── decorators/ # 自定义装饰器
│ ├── filters/ # 异常过滤器
│ ├── interceptors/ # 拦截器
│ └── guards/ # 守卫
├── config/ # 配置模块
└── database/ # 数据库配置
NestJS 特有规范
模块设计
每个功能模块自包含
使用 @Module() 装饰器
共享模块导出公共 Provider
控制器规范
使用 @Controller() 装饰器
方法使用 @Get/@Post/@Put/@Delete
参数使用 @Body/@Param/@Query
服务层规范
使用 @Injectable() 装饰器
构造函数注入依赖
业务逻辑在服务层
管道/过滤器
使用 Class Validator 做参数验证
全局异常过滤器处理错误
转换管道格式化响应
认证授权
使用 @nestjs/passport
JWT Strategy 实现
Guards 做权限控制
Roles 装饰器区分角色
## Java Spring Boot 项目
Java 生态里 Spring Boot 是yyds。这个框架和 Node.js 的风格完全不同,讲究的是一个"约定大于配置"。
```markdown
# AGENTS.md - Spring Boot 微服务项目
## 项目概述
基于 Spring Boot 的用户认证微服务,提供 JWT 认证、OAuth2 集成。
## 技术栈
- Java 17
- Spring Boot 3.2
- Spring Security
- Spring Data JPA
- MySQL 8.0
- Gradle
## 构建与运行
```bash
./gradlew build
./gradlew bootRun
./gradlew test
./gradlew bootJar
项目结构
src/
├── main/
│ ├── java/com/example/app/
│ │ ├── controller/ # REST 控制器
│ │ ├── service/ # 业务逻辑
│ │ ├── repository/ # 数据访问
│ │ ├── model/ # 实体类
│ │ ├── dto/ # 数据传输对象
│ │ ├── config/ # 配置类
│ │ └── exception/ # 异常处理
│ └── resources/
│ └── application.yml
└── test/
└── java/ # 测试代码
编码规范
使用 Lombok 减少样板代码
控制器返回 ResponseEntity
所有异常通过 @ExceptionHandler 处理
事务使用 @Transactional 声明
使用构造器注入(推荐)
测试规范
单元测试:JUnit 5 + Mockito
集成测试:@SpringBootTest
Controller 测试:@WebMvcTest
测试数据使用 @Sql 加载
部署说明
打包为 JAR:./gradlew bootJar
Docker:docker build -t app:latest .
环境变量参考 .env.example
## Go 项目
Go 后端现在也很火,特别是做高性能API服务的时候。我常用的是 Gin 框架。
```markdown
# AGENTS.md - Go REST API 项目
## 技术栈
- Go 1.21
- Gin Web 框架
- GORM ORM
- PostgreSQL
- Wire 依赖注入
## 开发命令
```bash
go mod download
go run cmd/api/main.go
go test ./...
go test -v -run TestXxx
go build -o bin/api cmd/api/main.go
项目结构
cmd/
api/
main.go
internal/
handler/ # HTTP 处理层
service/ # 业务逻辑层
repository/ # 数据访问层
model/ # 数据模型
middleware/ # 中间件
config/ # 配置
pkg/ # 可复用包
编码规范
遵循 Go 官方编码规范
使用 gofmt 格式化代码
错误处理:使用 fmt.Errorf + %w 包装
日志使用 zap 日志库
配置使用 Viper 框架
测试要求
单元测试使用标准库 testing
集成测试使用 testify 框架
Mock 使用 go mock 工具
覆盖率目标:70% 以上
注意事项
禁止使用 panic 处理业务错误
数据库连接使用连接池
敏感信息从环境变量读取
使用 context 传递请求上下文
## 后端AGENTS.md的特殊门道
后端项目有几个地方和前端不太一样,单独说说。
数据库操作一定要写清楚。后端最核心的就是数据处理,用什么ORM、数据库迁移怎么跑、测试数据怎么准备,这些都要写。要不然AI给你生成的代码可能连数据库连接都没有。
认证授权机制要说明白。JWT怎么用、Session怎么管理、OAuth怎么整,这些如果不写清楚,AI生成的接口很可能是不带认证的裸接口。
错误处理规范要统一。后端错误处理的方式很多,你得告诉AI用什么方式返回错误信息,是用HTTP状态码还是返回特定的错误格式。
事务处理规则要写明白。哪些操作需要事务、事务怎么控制,这些涉及到数据一致性的问题,AI自己是不可能搞清楚的。
## 小结
后端项目的AGENTS.md,前端篇讲的那套依然适用,但需要更多关注数据库、认证、错误处理这些后端特有的东西。不同的技术栈规范也不太一样,Node.js、Java、Go 各有各的玩法,你得根据自己选的技术栈来调整。
下期聊聊测试和代码重构场景,这是很多人容易忽略但其实特别重要的场景。
---
