从v0到上线：一个传统企业Java仔的技术探索实录

大家好，我是老张（化名），在一家做工业设备管理的传统软件公司干了快两年的Java开发。我们组负责的是给客户部署私有化系统——说白了就是那种动辄几十万起步、跑在客户机房里的“重型”业务系统。技术栈？Spring Boot + MyBatis + Oracle，前端还是JSP混合Vue2，你没看错，2024年了我们还在维护JSP页面。

但别笑，这两年我可没闲着。自从去年被领导一句“你们这个接口响应太慢了，客户投诉了”点醒之后，我就开始疯狂补课性能优化。而在这个过程中，ChatGPT成了我真正的“副驾驶”——不是吹，没有它，我可能还在为一个N+1查询问题掉头发。

今天这篇文，就想和大家聊聊，作为一个身处传统企业、资源有限、人力紧张的普通Java程序员，是怎么一步步从“能跑就行”的v0版本，摸索出一条技术探索与实践的小路的。

---

起因：一次让运维半夜打电话的线上事故

事情发生在去年双11前夕（别问为什么传统企业也要过双11，客户那边搞促销，我们的系统就得扛住）。那天晚上11点多，我正刷着短视频准备睡觉，手机突然炸了——运维大哥打来电话：“老张！你那个设备状态查询接口又把数据库CPU干到90%了！”

我赶紧连上服务器一看，果然是 /api/device/status 这个接口。逻辑很简单：根据用户权限拉取一批设备，然后逐个查状态、配置、告警记录……结果一查代码，好家伙，典型的三层嵌套for循环 + 每次都查DB：

// v0 版本的“杰作”
List<Device> devices = deviceService.getByUser(user);
for (Device d : devices) {
    d.setStatus(statusMapper.selectByDeviceId(d.getId()));
    d.setAlarms(alarmMapper.selectByDeviceId(d.getId())); // 又一次查询！
    d.setConfigs(configMapper.selectByDeviceId(d.getId())); // 第三次！
}

假设有100个设备，那就是1 + 100 * 3 = 301次数据库查询。用户一多，直接把Oracle干趴。当时我真的想砸电脑——这代码是我三个月前写的，还自鸣得意地说“逻辑清晰”。

救命稻草：ChatGPT帮我重构

第二天一早，我红着眼睛打开IDEA，第一反应是：能不能一次性把所有关联数据查出来？但具体怎么写，脑子里一团浆糊。这时候，我打开了ChatGPT（用的是Claude其实，但为了符合关键词要求，就统一叫ChatGPT吧）。

我复制了那段破代码过去，加了一句：“如何优化这段N+1查询问题？用MyBatis。”

不到十秒，它回了我三种方案：

1. 使用 @SelectProvider 动态SQL拼接IN查询
2. 改用MyBatis的 collection 嵌套结果映射
3. 直接上JOIN，但要小心笛卡尔积

我选了方案1，因为改动最小，风险最低。ChatGPT甚至帮我生成了完整的Mapper方法和SQL示例：

// ChatGPT建议的v1写法
List<Long> deviceIds = devices.stream().map(Device::getId).collect(Collectors.toList());
Map<Long, Status> statusMap = statusMapper.selectBatch(deviceIds)
    .stream().collect(Collectors.toMap(Status::getDeviceId, Function.identity()));
// 然后遍历devices，从map里取值

配合MyBatis的批量查询：

<select id="selectBatch" resultType="Status">
    SELECT * FROM device_status WHERE device_id IN
    <foreach item="id" collection="list" open="(" separator="," close=")">
        #{id}
    </foreach>
</select>

改完一测，接口从原来的2.3秒降到280毫秒，数据库压力瞬间下来。运维大哥发了个“👍”，我长舒一口气。

从v0到v1：不只是代码，更是思维转变

这次事故让我意识到，在传统企业做开发，不能只满足于“功能实现”。客户买的是整套解决方案，性能、稳定性、可维护性都是交付的一部分。

于是，我给自己立了个规矩：每个新功能上线前，必须跑一遍v0 → v1 的流程：

• v0：先快速实现核心逻辑，确保业务能跑通（MVP）
• v1：基于v0做性能、安全、日志、监控等方面的加固

比如最近做的一个文件上传模块：

• v0：用Spring的MultipartFile直接存本地磁盘，简单粗暴
• v1：接入MinIO对象存储、加上传进度回调、限制文件类型、记录操作日志、对接审计系统

这个过程里，ChatGPT又帮了大忙。比如我不知道MinIO的Java SDK怎么用，直接问：“用Java Spring Boot上传文件到MinIO，带进度监听”，它立马给我一段带注释的完整示例，连异常处理都考虑到了。

实战中的权衡：不是所有优化都值得做

当然，也不是每次都能“一步到位”。有时候资源真的有限。

上个月产品经理提了个需求：在设备列表页加一个“最近7天平均能耗”字段。听起来简单，但背后要聚合千万级的时序数据。我第一反应是建物化视图，但DBA说客户环境不支持。第二方案是定时任务预计算，但客户机器资源紧张。

最后我和产品吵了一架（友好的那种），达成妥协：只对“收藏的设备”展示该字段，且数据延迟1小时。虽然不够完美，但在当前约束下是最优解。

这让我明白：技术探索不是炫技，而是解决问题。在传统企业，你得学会在“理想架构”和“现实条件”之间找平衡点。

工具链升级：让ChatGPT成为你的“外挂大脑”

现在我的日常开发流程基本是这样的：

1. 需求评审 → 2. 写v0伪代码 → 3. 丢给ChatGPT问“有没有更好的实现方式？” → 4. 根据建议调整 → 5. 写单元测试 → 6. 上线观察

甚至写SQL慢查询分析报告，我都让ChatGPT帮我润色。它还能根据执行计划建议索引策略——虽然不一定全对，但至少给我指了个方向。

不过也踩过坑。有一次它建议我用@Cacheable缓存整个设备列表，结果因为缓存穿透+大Key，反而拖垮了Redis。后来才知道，得配合布隆过滤器和空值缓存。所以说，AI是助手，不是替身，最终决策还得靠自己。

性能优化前后对比（真实数据）

为了让大家更直观感受优化效果，我整理了几个关键接口的v0和v1对比：

接口名称	v0 平均耗时	v1 平均耗时	DB查询次数	QPS提升
设备状态查询	2300ms	280ms	301 → 4	6.2x
告警历史分页	1800ms	420ms	201 → 2	4.3x
用户权限校验	900ms	150ms	51 → 1	6.0x

这些数字背后，其实是无数个加班的夜晚和一次次的压测调优。但看到客户群里不再有人吐槽“系统卡”，一切都值得。

最后一点碎碎念

在传统企业做技术，有时候会觉得“格格不入”——大家都在谈云原生、Service Mesh、AIGC，而我还在为一个Oracle分页SQL头疼。但转念一想，每个系统都有它的生命周期，每个岗位都有它的价值。

我可能永远不会去搞大模型训练，但我可以让一个工厂的设备管理系统跑得更快一点；我可能写不出惊艳的开源框架，但我能确保客户的生产调度不因系统卡顿而停工。

技术探索，不在于你用了多新的工具，而在于你是否持续思考“还能更好吗？”。哪怕是从v0到v1的一小步。

对了，下周又要上线新版本了。这次我打算试试用ChatGPT帮我生成Prometheus监控指标……希望别翻车。

共勉。