Java后端实习经历分享

在大二暑假，我在一家小公司实习了一个半月，接触了实际开发后，可以说是受益匪浅，对计算机软件的理解有所提升。

系统设计

管理员权限

一个完善的产品应该给非专业管理员留下足够的管理空间。

在我第一次做项目时，我更注重于系统的可行性，但忽略了客户并不是专业人员。我眼中简单的操作并不适合他们进行管理。在沟通后，我在后台加入了大量供管理员修改的权限。

如：管理员可以调整页面的布局、决定什么能够展示，什么不能展示、新增或修改法务文件等。

系统的后续可修改性

在早期设计时，可能有些功能是不必要的，但我们仍应该将这些变量纳入考虑的范围中。

这样，当相关功能需要拓展时，就能更加游刃有余的应对。

git管理

一次我将修改提交后，提醒运维组员就走了。第二天队友跟我说自己搞砸了，希望我重新提交一遍。我查了Git记录后发现他和往常一样拉取了远程仓库，但我提的新功能都没有出现。

最后我排查原因时发现，是因为我在提交时没有修改代理端口，导致代码实际上没有推送到远程仓库。

这件事也让我意识到，“本地已经 commit”并不等于“远端已经更新”。关键改动推送后，最好确认远端分支的最新提交哈希已经变化，再通知其他人拉取代码。

线上与开发环境

在本地能运行的代码不一定能在线上环境正常工作。

在一次任务中，我实现了一个功能：统计商品点击量并进行排名。在开发环境的测试是没有问题的，但部署后客户却表示没有统计点击量。

通过浏览器网络追踪，我发现接口没有被触发，在网络层上根本找不到这个请求。

结合之前的经验，我判断问题和HTTPS有关：如果页面已经走HTTPS，但接口仍然是HTTP，浏览器会按混合内容策略直接拦截这类请求。也就是说，问题不只是“没有证书”，而是线上页面的协议和接口协议不一致。

安全重于一切

网络攻击的方式多种多样：SQL注入、供应链投毒（我记得这个很频繁，Apifox就中招过），很难做到绝对安全，但我们应该尽力保证系统的安全性，让破解成本高于对方攻击成功的利润。

测试要涵盖各种情况

在编写代码和测试时一定要考虑到所有情况。

比如用户注册时的昵称，一定要限长。按正常人的思维，用户名一般都不会太长，但这不代表这种情况不会发生。

开发工具

开源项目

若依

二开神器，地址

若依是一套比较成熟的Java后台管理系统脚手架，内置用户、角色、菜单、部门、字典、日志、定时任务等常见后台功能，也提供代码生成器。对于中小型管理系统来说，很多基础模块不需要从零写，直接基于它做二次开发，可以省下大量前期搭建时间。

我实习时接触的这个ruoyi-vue-pro，是在若依基础上扩展出来的版本，功能比官方版更丰富，比如多租户、支付、商城、工作流等模块都有对应实现。它的优点是生态和资料比较多，遇到问题时更容易找到参考；缺点是引入的功能多，结构也更重，实际使用时最好按业务裁剪依赖，而不是把所有模块都原样搬进项目。

各类SDK

如 WxJava

WxJava是一个封装了微信开放能力的Java SDK，覆盖公众号、小程序、微信支付、开放平台和企业微信等常用场景。它把access_token管理、签名、请求发送和结果解析这些重复工作封装好了，开发者可以直接调用对应的Service完成登录、获取手机号、下单、退款等操作。

以小程序支付为例，自己对接微信API需要处理证书、签名、回调验签等细节；使用WxJava后，业务代码只需要准备好商户号、订单号、金额和openid等参数，再调用支付服务生成调起支付的参数即可。这样不仅开发速度快，也能减少手写协议时的低级错误。

Docker

我本地的MySQL是5.7的，但上线要求是8.0。如何在保持本地不做修改的同时测试8.0环境下的程序运行？这正是Docker解决的问题。

例如可以用一个独立的容器启动 MySQL 8.0，把端口映射到本地，再把应用的连接信息指向这个容器。这样既不会污染本机的 MySQL 5.7 环境，也能提前暴露不同数据库版本带来的 SQL 兼容性问题。

1Panel

相较于宝塔，我认为1Panel的开源属性和容器化管理体验更符合我的需求。它可以直接管理Docker容器、镜像、网络和卷，也能配置网站、反向代理与SSL证书，让本地测试环境和线上部署环境更容易保持一致。

AI使用

一定要人为检查

在使用agent开发时，使用较强的模型、配置skill等方法可以提高AI开发的正确率，但是仍然会有风险，必须要进行人为校验。代码可以由AI开发，但提交在人，要为自己提交的代码负责。

我定义了一个Spring Boot的skill，每当有任务时，必须要跑JUnit和mvn test，全部成功后才能结束任务，有时候一轮任务需要跑70~90个test，人工校验和测试都没有出现问题。因此我逐渐放松了审查，一些简单的任务直接让agent去实现。

但有一天，客户突然@我，询问站中查询的商品只有24条，怎么看到剩余的商品。我复现后理解去审查代码，发现分页功能只留了接口占位，没有实际实现。这一块我没有做代码审查，测试时本地数据量小，没有触发分页，导致这个问题直接暴露给了客户。

逻辑缺失问题

新增一个排行的功能，AI返回了商品的id。但搜索界面不支持通过id进行搜索，导致实际上排行是失败的，因为客户仍不能知道排行上的商品具体是什么。

skill的去留

现在的一些旗舰模型，如GPT-5.6-Sol、Claude Ops 5等综合能力已经很强，已经不太需要skill来指导它们怎么做任务。

我的想法是：现在可以放弃那些简单的，只是指导AI怎么进行常规任务的skill，而留下那些用于专业任务特化、优化人机交互（JavaGuide在一篇公众号中推荐了）的skills。

之前在测试一个新模型时，我给它发布了一个简单的代码阅读任务，目标是我的一个SSM系统。但却触发了我Vivado的skill，这样反而会对agent的工作起反作用。所以我认为，skill在精不在多，应该有选择性的保留skill。

codegraph

codegraph是我比较推荐的一个MCP。它可以把项目中的类、方法、调用关系等建立成索引，帮助agent快速定位符号、分析依赖和理解代码结构，而不需要在每次任务里盲目搜索整个仓库。

对于较大的Java后端项目来说，这类索引型MCP尤其适合配合AI使用：先让agent通过codegraph找到入口方法和上下游关系，再阅读相关代码并执行修改，能明显减少误改范围过大的情况。