30分钟用飞算JavaAI跑通JWT认证实测记录

实测目标：30分钟跑通完整JWT认证链路

这次测试不是看AI能写多少行代码，而是验证它能否在半小时内交付一个可编译、可启动、可调试、有失败路径的完整Java后端工程。需求很明确：从零搭建一个带用户注册、JWT登录、文章CRUD、作者权限控制和Knife4j文档的Spring Boot项目。

计时规则也很简单：提交需求开始，到Maven构建通过、Spring Boot启动成功，并在Knife4j中完成注册、登录、JWT鉴权和文章接口验收为止。最终总耗时正好30分钟——这已经包含了依赖下载、项目构建、服务启动和接口调试的全部时间。

提交的需求不是一句“写个登录”

为了让结果有实际参考价值，我给飞算JavaAI的提示词包含了技术栈、业务规则和验收标准：

• Spring Boot 3.2 + JDK 17 + Maven
• MyBatis-Plus + H2内存数据库
• 使用JJWT实现JWT生成与解析，通过拦截器鉴权
• 注册/登录无需Token，其余接口必须鉴权
• 登录成功返回Bearer Token，密码需BCrypt哈希
• 用户可对Article增删改查，但author必须来自当前JWT
• 只有作者本人能更新或删除文章
• 启用Spring Validation参数校验
• 统一Result响应与全局异常处理
• 集成Knife4j提供接口文档和在线调试
• 项目能直接Maven启动并通过核心场景验收

这个需求里有几个容易“看起来能用、实际上不闭环”的坑：JWT不只是发Token，还要保护接口；author不能信任客户端传值；越权操作必须拒绝。这些才是检验生成质量的关键。

生成结果：25个文件，7个接口，13条测试全过

30分钟后，项目已具备完整分层结构：controller、service、mapper、entity、dto、vo、security、config、exception 和 common。共生成25个主Java源文件，对外提供7个REST接口：

• POST /api/auth/register（无需Token）
• POST /api/auth/login（无需Token）
• POST /api/articles（需Token，author自动填充）
• GET /api/articles（需Token）
• GET /api/articles/{id}（需Token）
• PUT /api/articles/{id}（需Token且仅作者）
• DELETE /api/articles/{id}（需Token且仅作者）

执行 mvn clean test package 成功构建，生成约37MB的可执行JAR。测试报告显示13条用例全部通过，覆盖了：

• Spring上下文启动与H2表初始化
• 注册成功且不泄露密码
• 重复用户名返回409
• 正确登录返回Token，错误密码返回401
• 非法参数返回400
• 无Token访问文章接口返回401
• Knife4j文档路径无需登录
• 登录用户完成文章CRUD
• 非作者操作返回403
• 不存在资源返回404

关键逻辑复核：不只是骨架

JWT拦截器真正做了身份验证

拦截器不仅检查Authorization头是否存在，还会：

1. 验证Token是否以Bearer 开头
2. 解析Token获取用户名
3. 查询数据库确认用户仍存在
4. 将用户名写入请求属性供后续使用
5. 对缺失、空白、过期或非法Token统一返回401

同时，拦截器配置排除了/api/auth/**、/doc.html、/v3/api-docs等路径，确保文档页可直接访问，而业务接口强制鉴权。

密码处理符合安全实践

注册时使用BCryptPasswordEncoder对密码哈希存储，登录时通过matches方法比对。更关键的是，用户不存在和密码错误统一返回“用户名或密码错误”，避免攻击者通过错误信息枚举有效账号。

代码还显式处理了BCrypt的72字节限制，防止长密码被静默截断导致验证失败。

作者字段由服务端强制写入

文章创建接口的DTO只接收title和content，author字段在Service层从已验证的JWT中获取：

复制public Article create(ArticleRequest request, String username) {
    Article article = new Article();
    article.setTitle(request.title().trim());
    article.setContent(request.content());
    article.setAuthor(username); // 来自JWT，非客户端
    article.setCreatedAt(LocalDateTime.now());
    articleMapper.insert(article);
    return article;
}

更新和删除前会调用requireAuthor方法校验当前用户是否为原作者，否则抛出403异常。这从源头上杜绝了客户端伪造author的可能性。

异常状态映射到正确HTTP码

项目没有采用“HTTP永远200，错误塞进业务字段”的反模式，而是通过@RestControllerAdvice将不同异常映射到标准状态码：

• 参数校验失败 → 400
• 未登录 → 401
• 无权限 → 403
• 资源不存在 → 404
• 用户名冲突 → 409
• 服务器异常 → 500
• 创建成功 → 201

这种设计让Knife4j能正确展示各接口的可能响应，也便于客户端统一处理错误。

Knife4j验收：纯后端也能完整调试

项目没有开发任何前端页面，所有交互通过http://localhost:8080/doc.html完成：

1. 先注册再登录：注册接口有Validation约束（用户名3-20字符，密码6-32字符），成功返回201；登录使用相同凭据，成功返回包含token、tokenType和过期时间的JSON。

2. 配置全局鉴权：在Knife4j的Authorize页面填入Bearer <token>后，后续调试文章接口会自动携带Authorization头。

3. 文章接口全流程验证：

   • 新增：只传title/content，响应中author自动匹配当前用户
   • 列表：按createdAt倒序返回
   • 详情：有效ID返回200，无效ID返回404
   • 更新/删除：本人操作返回200，他人操作返回403

Knife4j还支持导出离线文档（Markdown/HTML/Word）、配置全局参数、缓存请求体等，说明OpenAPI集成是完整的，不只是个能打开的空页面。

客观评价：快在哪，风险在哪

确实提升效率的地方

复杂需求拆解完整：一次生成涵盖Spring MVC、MyBatis-Plus、JJWT、Validation、Knife4j和权限控制的分层项目，而不是单个Controller示例。

样板工程串联高效：POM依赖、配置类、实体、Mapper、Service、Controller、DTO、拦截器、异常处理器和OpenAPI配置相互配合，大幅缩短从空目录到可调接口的时间。

验收闭环超出预期：不仅有成功路径，401/403/404/409等失败场景均有对应实现和测试，这对认证类项目至关重要。

仍需人工介入的风险点

安全配置不能直接用于生产：

• JWT密钥使用了示例默认值，生产环境应通过环境变量或密钥管理服务注入
• H2内存数据库仅适合演示，生产需替换为MySQL/PostgreSQL等
• 缺少Token吊销、刷新机制、操作审计日志和API限流

环境一致性需注意：项目目标JDK 17，但本地Maven由JDK 26启动。虽然字节码已确认为Java 17（major version 61），团队项目应在IDE、CI/CD和部署环境统一JDK版本。

效率数据不可直接外推：本次无同机手写对照，也未拆分生成/检查/调试各阶段耗时，30分钟仅作为单次交付记录，不代表普遍提速比例。

结论：压缩骨架搭建时间，释放人力聚焦验证

这次测试证明，飞算JavaAI能在30分钟内将一份包含认证、授权、数据访问、参数校验和接口文档的Java需求，转化为可运行、可验证的工程起点。它没有替代开发者判断，而是把“搭脚手架”的时间大幅压缩，让开发者能更专注于：

• 业务规则是否准确落地（如author防伪造）
• 安全配置是否合规（如密钥管理）
• 异常和越权场景是否覆盖完整
• 运行环境是否一致

对于需要快速验证想法、搭建原型或生成标准化CRUD模块的场景，这类工具确实能带来实质性效率提升。但距离“生成即生产”仍有距离——安全、性能、可观测性等非功能需求仍需人工补充和审查。