Java 服务端开发标准

适用技术栈：Java 8+ / Spring Boot / MyBatis  |  版本：v1.5  |  生效日期：2026-08-24

一、工程结构规范（MVC 分层）

1.1 标准工程结构

统一采用 MVC 三层结构：接口写在 Controller，业务逻辑写在 Service，数据库查询写在 Mapper。

project-name/
└── src/main/java/com/company/project/
    ├── controller/            # 接口层：参数接收与校验、调用 Service、返回结果
    │   ├── OrderController.java
    │   └── UserController.java
    ├── service/               # 业务层：接口定义 + 实现，承载全部业务逻辑
    │   ├── OrderService.java        # 订单业务接口类
    │   ├── UserService.java         # 用户业务接口类
    │   └── impl/
    │       ├── OrderServiceImpl.java
    │       └── UserServiceImpl.java
    ├── mapper/                # 数据层：数据库查询，不含业务逻辑
    │   ├── OrderMapper.java
    │   └── UserMapper.java
    ├── model/
    │   ├── entity/            # 实体类
    │   ├── dto/               # 入参对象
    │   └── vo/                # 返回对象
    ├── enums/                 # 枚举类
    ├── config/                # 配置类
    ├── common/                # 常量、统一返回体、全局异常处理
    └── Application.java

1.2 各层职责边界

1.3 订单模块示例（接口类 + 实现 + 数据层）

// ── Controller：只做参数接收与调用 ──
@RestController
@RequestMapping("/api/v1/order")
public class OrderController {

    @Resource
    private OrderService orderService;

    /**
     * 创建订单接口
     */
    @PostMapping("/create")
    public Result<OrderDetailVO> createOrder(@RequestBody @Valid OrderCreateDTO dto) {
        return Result.success(orderService.createOrder(dto));
    }
}

// ── Service 接口类：订单业务契约 ──
public interface OrderService {

    /**
     * 创建订单
     */
    OrderDetailVO createOrder(OrderCreateDTO dto);

    /**
     * 根据订单号查询订单详情
     */
    OrderDetailVO getOrderDetailByOrderNo(String orderNo);
}

// ── ServiceImpl：业务逻辑全部在此 ──
@Service
public class OrderServiceImpl implements OrderService { ... }

// ── Mapper：只写数据库查询 ──
@Mapper
public interface OrderMapper {

    /**
     * 新增订单
     */
    int insert(OrderInfo order);

    /**
     * 根据订单号查询订单
     */
    OrderInfo selectByOrderNo(@Param("orderNo") String orderNo);
}

二、类名命名规范（驼峰写法）

2.1 各类对象命名模板

2.2 示例

// 正确：大驼峰，职责清晰
public class OrderPayService { }

// 错误：下划线、拼音、全小写
public class Order_Pay_Service { }
public class DingDanFuWu { }

三、方法名规范（见名知意）

方法名使用小驼峰（lowerCamelCase），必须能表达方法意图——看方法名即可知道它做什么，不需要读实现。

3.1 命名公式

3.2 正反示例

// 错误：看不出意图，需要读实现才知道干什么
public void handle(Order order) { }
public List<Order> query1(Long userId) { }
public boolean doCheck(Object o) { }

// 正确：方法名即文档
public void payOrder(Order order) { }
public List<Order> queryUnpaidOrdersByUserId(Long userId) { }
public boolean checkOrderWithinPayDeadline(Order order) { }

四、实体类命名规范

• 实体类名使用大驼峰，与数据库表名对应：表 order_info → 实体 OrderInfo。
• 实体类字段与表字段对应，Java 侧小驼峰：order_no → orderNo。
• 禁止在实体类上使用 @Data 同时可变共享（多线程场景）；推荐 @Getter/@Setter 显式控制。
• DTO（入参）、VO（出参）与 Entity 分离，禁止一个类既当实体又当接口对象。

五、实体类注释规范

必须每个实体类具备完整注释：类注释 + 全部字段注释，字段注释与数据库字段 COMMENT 保持一致。

5.1 注释模板

/**
 * 订单信息实体
 * 对应表：order_info
 *
 * @author zhangsan
 * @date 2026-08-24
 */
@Data
@TableName("order_info")
public class OrderInfo {

    /** 主键ID（雪花算法生成） */
    private Long id;

    /** 订单编号（业务唯一） */
    private String orderNo;

    /** 用户ID（关联 user_info.id） */
    private Long userId;

    /** 订单金额（单位：分） */
    private Long orderAmount;

    /** 订单状态 0-待支付 1-已支付 2-已取消 3-已完成（见 OrderStatusEnum） */
    private Integer orderStatus;

    /** 创建时间 */
    private Date createTime;

    /** 更新时间 */
    private Date updateTime;

    /** 逻辑删除标识 0-正常 1-已删除 */
    private Integer isDeleted;
}

5.2 字段注释要求

六、方法注释与业务流程注释规范

6.1 通用方法注释模板

必须所有方法具备 Javadoc 注释：说明用途、参数、返回值、异常。

/**
 * 根据用户ID查询未支付订单列表
 *
 * @param userId   用户ID，不可为空
 * @param pageNum  页码，从 1 开始
 * @param pageSize 每页条数，最大 100
 * @return 未支付订单分页结果，无数据时返回空分页对象
 * @throws BusinessException 用户不存在时抛出（错误码 20001）
 */
public Page<OrderInfo> queryUnpaidOrdersByUserId(Long userId, int pageNum, int pageSize) { }

6.2 核心业务功能：完整业务流程注释

必须核心业务方法（订单创建、支付回调、状态流转等）在方法内部按步骤编号写清业务流程，步骤注释使用 STEP x: 格式：

/**
 * 创建订单（核心业务）
 * 业务流程：参数校验 → 商品与价格校验 → 幂等校验 → 生成订单 → 扣减库存 → 发送延迟取消消息
 */
@Transactional(rollbackFor = Exception.class)
public OrderInfo createOrder(OrderCreateDTO dto) {

    // STEP 1: 参数基础校验（商品、数量、地址非空）
    checkCreateOrderParams(dto);

    // STEP 2: 查询商品信息并校验上架状态、价格以服务端为准（防止前端篡改价格）
    ProductInfo product = productMapper.selectById(dto.getProductId());
    checkProductSellable(product);

    // STEP 3: 幂等校验，同一幂等键的重复请求直接返回已存在订单
    OrderInfo existOrder = queryOrderByIdempotentKey(dto.getIdempotentKey());
    if (existOrder != null) {
        return existOrder;
    }

    // STEP 4: 生成订单编号并落库（金额单位为分，取服务端价格计算）
    OrderInfo order = buildOrder(dto, product);
    orderMapper.insert(order);

    // STEP 5: 扣减库存（库存不足抛业务异常，事务回滚订单）
    productMapper.deductStock(product.getId(), dto.getProductCount());

    // STEP 6: 发送延迟消息，超时未支付自动取消订单（消息发送失败仅告警，不回滚）
    sendDelayCancelMessage(order);

    return order;
}

6.3 注释等级要求

七、方法体行数与公共方法抽离

7.1 拆分方法示例

// 错误：一个方法 400+ 行，参数校验、金额计算、落库、通知全部堆在一起
public void createOrder(OrderCreateDTO dto) {
    // ...300 行混合逻辑...
}

// 正确：按业务步骤抽成私有方法，主方法只保留流程骨架
public void createOrder(OrderCreateDTO dto) {
    checkCreateOrderParams(dto);          // 抽离：参数校验
    OrderInfo order = buildOrder(dto);    // 抽离：组装订单（金额计算复用 calcOrderAmount）
    saveOrder(order);                     // 抽离：订单落库
    notifyUserOrderCreated(order);        // 抽离：用户通知
}

// 抽离出的公共方法：多处复用的金额计算
private Long calcOrderAmount(Long unitPrice, Integer count, Long discountAmount) {
    return unitPrice * count - discountAmount;
}

7.2 抽离判断流程

1. 出现第二次复制粘贴 → 立即抽公共方法（禁止“先复制，后面再改”）；
2. 方法超 300 行 → 按业务步骤拆分为多个私有方法，主方法只保留流程编排；
3. 私有方法被第二个类需要 → 上移到工具类或公共 Service；
4. 抽离的方法遵循第三条规范：方法名表达意图。

八、禁止魔法值，统一使用枚举

魔法值（Magic Value）指代码中直接硬编码的数字或字符串常量。必须用枚举类或常量类替代。

8.1 正反示例

// 错误：魔法值，1、2、"PAID" 散落各处，含义不明、改不动
if (order.getStatus() == 2) { ... }
if ("PAID".equals(payResult)) { ... }

// 正确：枚举统一收口
if (OrderStatusEnum.PAID.getCode().equals(order.getOrderStatus())) { ... }
if (PayResultEnum.PAID.getCode().equals(payResult)) { ... }

8.2 标准枚举模板

/**
 * 订单状态枚举
 *
 * @author zhangsan
 * @date 2026-08-24
 */
@Getter
@AllArgsConstructor
public enum OrderStatusEnum {

    /** 待支付 */
    UNPAID(0, "待支付"),

    /** 已支付 */
    PAID(1, "已支付"),

    /** 已取消 */
    CANCELED(2, "已取消"),

    /** 已完成 */
    FINISHED(3, "已完成");

    /** 状态码（对应 order_info.order_status） */
    private final Integer code;

    /** 状态描述 */
    private final String desc;

    /**
     * 根据 code 获取枚举
     */
    public static OrderStatusEnum getByCode(Integer code) {
        for (OrderStatusEnum e : values()) {
            if (e.code.equals(code)) {
                return e;
            }
        }
        return null;
    }
}

8.3 使用原则

九、数据库设计规范

9.1 强制规则

9.2 标准建表模板

CREATE TABLE `order_info` (
  `id`            bigint(20)    NOT NULL                COMMENT '主键ID（雪花算法生成）',
  `order_no`      varchar(32)   NOT NULL                COMMENT '订单编号（业务唯一）',
  `user_id`       bigint(20)    NOT NULL                COMMENT '用户ID（逻辑关联 user_info.id，无物理外键）',
  `order_amount`  bigint(20)    NOT NULL DEFAULT 0      COMMENT '订单金额（单位：分）',
  `order_status`  tinyint(4)    NOT NULL DEFAULT 0      COMMENT '订单状态 0-待支付 1-已支付 2-已取消 3-已完成',
  `remark`        varchar(256)  DEFAULT NULL            COMMENT '订单备注',
  `create_time`   datetime      NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `update_time`   datetime      NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  `is_deleted`    tinyint(4)    NOT NULL DEFAULT 0      COMMENT '逻辑删除 0-正常 1-已删除',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_order_no` (`order_no`),
  KEY `idx_user_id` (`user_id`),
  KEY `idx_create_time` (`create_time`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单信息表';

9.3 字段长度选型参考

十、SQL 与查询禁项规范

10.1 正反示例

// 错误：循环内逐条查库（N+1 问题）
for (OrderItem item : items) {
    ProductInfo p = productMapper.selectById(item.getProductId());  // 禁止：循环代码块内查询数据库
}

// 正确：一次批量查询 + 内存组装
List<Long> productIds = items.stream().map(OrderItem::getProductId).collect(Collectors.toList());
Map<Long, ProductInfo> productMap = productMapper.selectBatchByIds(productIds)
        .stream().collect(Collectors.toMap(ProductInfo::getId, Function.identity()));

// 错误：一张 SQL 关联 7 张表，难以维护、易超时，禁止
SELECT o.*, u.*, p.*, c.*, s.*, a.*, r.*
FROM order_info o
JOIN user_info u    ON o.user_id = u.id
JOIN product_info p ON o.product_id = p.id
// ... 继续 JOIN 至 7 张表（超过 5 张，禁止）

// 正确：拆分为多次单表/少量关联查询，内存组装结果
OrderInfo order = orderMapper.selectByOrderNo(orderNo);
UserInfo user = userMapper.selectById(order.getUserId());
ProductInfo product = productMapper.selectById(order.getProductId());

// 错误：大表无 WHERE 条件的全表查询，禁止
SELECT * FROM order_info;  // 全表扫描，大表直接拖垮 DB

// 正确：带索引条件 + 限制返回行数
SELECT id, order_no, order_status FROM order_info
WHERE user_id = #{userId} AND create_time >= #{startTime}
ORDER BY id DESC LIMIT 50;

十一、接口统一返回体规范

必须所有接口统一返回 Result<T> 结构，禁止 Controller 各写各的返回格式。

11.1 统一返回结构

{
  "code": 0,            // 0=成功，非0=错误码（见12.3错误码分段）
  "message": "success", // 提示信息，可直接展示给用户
  "data": { }           // 业务数据，失败时为 null
}

11.2 规则

• Result 定义在 common 模块，全工程唯一，禁止每个服务自定义一套；
• 分页返回统一 data = { list, total, pageNum, pageSize }；
• 金额字段用分（long）传输，时间字段统一毫秒时间戳，全局约定一致；
• 成功返回 Result.success(data)，失败抛 BusinessException 由全局异常处理器转 Result，Controller 内禁止手写 try-catch 拼 error 返回。

十二、全局异常处理规范

必须使用 @RestControllerAdvice 全局异常处理器统一捕获，Controller / Service 内禁止散落 try-catch 拼 JSON。

12.1 异常分类

12.2 规则

• 异常日志必须包含完整上下文（入参、traceId、用户标识），堆栈对象作为日志最后一个参数：log.error("msg:{}", ctx, e)；
• 禁止 catch (Exception e) 后吞掉不处理、不打日志；
• 禁止在循环内抛异常做流程控制；
• 对外错误信息禁止暴露内部细节（表名、SQL、堆栈）。

12.3 错误码分段

十三、日志规范

13.1 框架与级别

• 统一 SLF4J + Logback，@Slf4j 注解声明；必须禁止 System.out.println；

13.2 格式要求

// 错误：拼接 + 无上下文 + 丢堆栈
log.info("下单成功");
log.error("错误:" + e.getMessage());

// 正确：占位符 + 业务标记 + 上下文 + 完整堆栈
log.info("[ORDER_CREATE] userId={}, productId={}, amount={}", userId, productId, amount);
log.error("[ORDER_CREATE] create failed, dto={}", dto, e);

• 关键业务日志带 [业务标记] 前缀，便于按场景检索；
• traceId 由 MDC 注入贯穿全链路；
• 手机号、身份证、密码等敏感字段强制脱敏。

十四、线程池规范

• 必须禁止裸 new Thread()，统一通过 ThreadPoolExecutor 显式创建，禁止 Executors.newFixedThreadPool / newCachedThreadPool（无界队列 OOM 风险）；
• 线程池必须自定义 ThreadFactory 命名（如 order-pay-pool-%d），便于线程栈排查；
• 核心数 / 最大数 / 队列容量 / 拒绝策略必须按业务评估显式配置，拒绝策略须记录日志或有兜底；
• 线程池参数收口到 Nacos 配置，可动态调整（配置变更按第十九条同步归档）；
• 共享可变状态用 ConcurrentHashMap 等并发容器；SimpleDateFormat 换 DateTimeFormatter。

ThreadPoolExecutor executor = new ThreadPoolExecutor(
        4, 8, 60, TimeUnit.SECONDS,
        new LinkedBlockingQueue<>(1000),
        new ThreadFactoryBuilder().setNameFormat("order-pay-pool-%d").build(),
        new ThreadPoolExecutor.CallerRunsPolicy());

十五、幂等规范

• 必须创建类接口（下单、支付发起、退款申请）支持幂等 key：客户端生成唯一键，服务端重复请求直接返回首次结果；
• 支付回调、MQ 消费强制幂等：以业务单号 + 状态做防重，处理前先查处理结果；
• 状态流转幂等：重复触发"已支付→已取消"类非法流转返回明确错误而非静默成功；
• 幂等实现优先 Redis setnx（带 TTL），强一致场景用数据库唯一索引兜底；
• 更新类接口带版本号（乐观锁）：UPDATE ... SET version = version + 1 WHERE id = ? AND version = ?。

十六、鉴权与越权防护规范

• 必须所有对外接口鉴权，白名单仅限登录、健康检查，白名单显式配置并评审；
• 鉴权统一由框架层（拦截器 / 网关）完成，权限注解化：@RequiresPermissions("order:cancel")；
• 资源级越权校验：按 ID 操作资源（查订单、改地址）时，必须校验资源归属于当前用户，禁止只校验登录态；
• 用户角色 / 权限变更后旧 token 处理策略明确（踢下线或短有效期）；
• 日志与监控不记录完整 token / 密码。

// 错误：只校验登录，未校验归属 → 水平越权
public OrderDetailVO getOrderDetail(String orderNo) {
    return orderMapper.selectByOrderNo(orderNo);  // 任意登录用户可查任意订单
}

// 正确：归属校验
public OrderDetailVO getOrderDetail(Long userId, String orderNo) {
    OrderInfo order = orderMapper.selectByOrderNo(orderNo);
    if (order == null || !userId.equals(order.getUserId())) {
        throw new BusinessException(OrderErrorCode.ORDER_NOT_EXIST);
    }
    return convert(order);
}

十七、防注入规范

十八、单元测试规范

• 核心业务（订单、支付、状态流转）、工具类、复杂算法必须有单测，行覆盖率 ≥ 70%；
• 测试与生产代码同包结构，命名 原类名 + Test（OrderServiceImplTest）；
• 单测不依赖真实数据库 / Redis / 第三方，外部依赖 Mock（Mockito）；
• 单测方法名表达场景：createOrder_shouldThrow_whenProductOffShelf；
• 边界用例必备：null 入参、空集合、金额 0 / 负数、超长字符串、并发重复请求；
• 单测随代码同一次提交 Git，commit 标注：[订单] feat: 新增取消接口（含单测）。

十九、Git 提交与配套产物同步规范

19.1 每日提交要求

19.2 提交备注（Commit Message）规范

备注必须写清修改内容，格式：[模块] 类型: 修改内容

// 错误：无法追溯
git commit -m "修改"
git commit -m "fix bug"
git commit -m "更新代码"

// 正确：模块 + 类型 + 具体内容
git commit -m "[订单] feat: 新增订单取消接口，超时未支付自动取消"
git commit -m "[用户] fix: 修复登录token刷新并发覆盖问题"

19.3 数据库 DDL 同步提交

必须凡是涉及数据库修改（新增表、加字段、改索引等），DDL 脚本必须与代码同一次提交入库：

• DDL 文件统一放在工程 doc/sql/（或 sql/ddl/）目录，按日期 + 序号命名：20260824_01_add_pay_channel_to_order_info.sql
• DDL 内容包含完整的变更语句与回滚语句，表结构变更同步更新表 COMMENT
• 禁止只在测试库手工改表而代码库无 DDL 记录——环境无法重建，事故无法追溯

-- 20260824_01_add_pay_channel_to_order_info.sql
-- 变更：order_info 新增支付渠道字段
ALTER TABLE `order_info`
    ADD COLUMN `pay_channel` tinyint(4) NOT NULL DEFAULT 0 COMMENT '支付渠道 0-微信 1-支付宝 2-余额' AFTER `order_status`;

-- 回滚
ALTER TABLE `order_info` DROP COLUMN `pay_channel`;

19.4 Nacos 配置同步提交

必须凡是使用 Nacos 配置中心，修改配置后必须同步提交配置文件到代码库：

• 配置文件按环境归档：doc/nacos/{dev|test|prod}/xxx-service.yaml，与 Nacos 控制台内容保持一致
• 在 Nacos 控制台改配置的同时（或当日）提交对应文件，commit 标注 config 类型与改动项
• 敏感信息（密码、密钥）在归档文件中脱敏，并在文件头注明“脱敏归档，真实值见 Nacos”
• 上线检查清单必须包含：代码 ✓ / DDL ✓ / Nacos 配置文件 ✓ 三者齐备才可发版

二十、AI 协作：新功能开发文档先行

必须AI 编写新功能点时，必须先生成开发文档，人工确认文档没问题后，再生成代码。禁止跳过文档直接产出代码。

20.1 标准流程

需求输入
   │
   ▼
① AI 生成开发文档（接口设计、表结构、业务流程、影响范围）
   │
   ▼
② 人工评审开发文档 ── 不通过 ──→ 补充/修正文档，重新评审
   │ 通过
   ▼
③ AI 按已确认的文档生成代码
   │
   ▼
④ 人工 Code Review + 测试验证

20.2 开发文档必备内容

二十一、AI 协作：功能修改文档先改

必须AI 修改已有功能时，必须先修改开发文档，文档确认没问题后，再修改代码，保证文档与代码始终一致。

21.1 标准流程

1. 改文档：AI 先定位对应功能的开发文档，修改受影响的章节（接口字段、业务流程、枚举、DDL）；
2. 人工确认：评审文档变更是否与修改意图一致；
3. 改代码：确认通过后，AI 按更新后的文档修改代码；
4. 一致性校验：Code Review 时同步核对"文档描述 = 代码实现"。

二十二、AI 协作：开发文档同步提交 Git

必须AI 编写的开发文档与代码一并提交到 Git，纳入版本管理，与代码同仓库、同分支、同节奏。

22.1 文档归档规则

22.2 提交要求

• 开发文档与对应代码同一次提交（或文档先行提交），commit 备注标注文档变更：[订单] feat: 新增订单取消接口（含开发文档 doc/design/order_cancel_20260824.md）
• 修改功能的场景，文档变更与代码变更同一次提交，保证任意 commit 节点文档与代码可对齐回溯；
• 文档使用 Markdown 格式，随功能演进持续更新，禁止归档后失管。

二十三、部署文档规范

必须项目部署必须编写部署文档，与项目同仓库归档（doc/deploy/{项目名}_{环境}_部署文档.md）。部署文档是项目可交付的一部分：任何一名新成员仅凭该文档即可完成部署、排障与恢复，禁止"只在部署者脑中"的隐性部署知识。

23.1 部署文档必备内容

23.2 部署文档模板

# {项目名} 部署文档

## 1. 基本信息
- 服务器：{IP}（用途：生产/测试）
- 项目版本：v1.2.0（分支 master / commit abc1234）
- 组件版本：JDK 1.8 / MySQL 8.0 / Redis 6.2 / Nginx 1.24 / Nacos 2.2

## 2. 部署路径
| 对象 | 路径 | 说明 |
|---|---|---|
| 应用 jar | /opt/java/app.jar | Spring Boot 应用 |
| 前端资源 | /opt/web/dist | Vue 构建产物 |
| Nginx 配置 | /etc/nginx/nginx.conf | 反向代理 |
| MySQL | docker 容器 mysql-8.0，数据 /data/mysql | 持久化目录 |
| Redis | docker 容器 redis，配置 /etc/redis.conf | 密码见第5节 |

## 3. 启动与停止
- 应用启动：cd /opt/java && nohup java -jar app.jar --spring.profiles.active=prod > app.log 2>&1 &
- 应用停止：ps -ef | grep app.jar | grep -v grep | awk '{print $2}' | xargs kill
- 组件重启：docker restart mysql-8.0 / docker restart redis
- 日志查看：tail -f /opt/java/app.log；docker logs -f --tail 200 mysql-8.0

## 4. 端口与依赖
- 端口：80（Nginx）、8080（应用）、3306（MySQL）、6379（Redis）
- 启动顺序：MySQL → Redis → Nacos → 应用 → Nginx

## 5. 账号密码（脱敏，明文见密码管理渠道 {渠道名}）
- SSH：devops / ********
- MySQL：root / ********（业务库 {db_name}）
- Redis：requirepass ********

## 6. 注意事项
- 部署前先执行 doc/sql/ 下新增 DDL（按文件名日期顺序）
- 新增 Nacos 配置项需同步更新 doc/nacos/prod/ 归档
- 回滚：保留上一版本 app.jar.bak，替换后重启即可

23.3 更新与提交要求

• 必须部署结构发生变化（换路径、换组件、改端口、改启动方式）时，同步更新部署文档，与代码同一次提交 Git；
• 必须首次部署、环境迁移、组件升级后，由未参与部署的成员按文档验证一次可复现性；
• 应当将部署文档链接写入项目 README，保证新人可直接定位；
• 必须文档中账号密码脱敏展示，明文密码统一放密码管理渠道（如公司密码库），文档只写获取方式，禁止明文密码入 Git。

附录一：Code Review 检查清单

附录二：AI 协作开发流程总览

新功能：需求 → ① AI生成开发文档 → ② 人工确认文档 → ③ AI生成代码 → ④ Code Review → ⑤ 文档+DDL+配置+代码 一并提交 Git
修改功能：变更需求 → ① AI先改开发文档 → ② 人工确认文档 → ③ AI按文档改代码 → ④ Review核对文档与实现一致 → ⑤ 一并提交 Git

Java 服务端开发标准 v1.5  |  2026-08-24 发布  |  修订记录：v1.0 初版（10 条核心规则）；v1.1 新增第 11~13 条 AI 协作流程规范；v1.2 新增第 14~22 条（统一返回体、全局异常、日志、SQL 禁项、线程池、鉴权越权、防注入、幂等、单元测试）；v1.3 按归类重排为八大部分，章节编号连续化（1~22）；v1.4 新增第九部分部署规范（第 23 条：部署文档必备内容与模板）；v1.5 第十条 SQL 与查询禁项新增「循环内查库、复杂 SQL JOIN 表数上限（≤5）、大表禁止全表查询」校验规则及正反示例