今天的任务不算特别多，主要是下午服务器环境出了问题，项目一直访问不稳定，调试被耽误了不少时间。最终只完成了两个主要事项：上午修复了一个申报数据报价完成状态的 Bug，下午排查了一个碳排放统计接口中总量指标为负数的问题。

虽然代码量不大，但这两个问题都比较典型：一个涉及业务状态的自动维护，另一个涉及数据统计口径的排查。对我这个 Java 实习生来说，收获还是比较明显的。

一、补全申报数据的报价完成状态校验

上午处理的是一个禅道 Bug，和申报数据中的“是否完成基础报价”字段有关。

系统中有一类案例数据，案例下会关联多个设备。用户可以通过导入、编辑、批量生成等方式维护设备的分段报价数据。另一个页面会展示当前案例是否完成基础报价，但原有逻辑在部分操作场景下没有及时更新这个状态，导致前端展示和实际数据不一致。

这个需求的核心规则是：

如果当前案例下每个设备都至少有一条有效报价记录，
则标记为完成基础报价；
否则标记为未完成。

我先梳理了数据变化入口，发现导入、编辑保存、批量生成报价都会影响这个状态。因此不能只在某一个接口里加判断，而是要保证所有相关操作完成后都触发校验。

服务层中原本已经有一部分校验逻辑，但关联条件不够完整。我根据当前案例下的设备列表，重新按“案例 ID + 设备 ID”查询对应报价记录，避免把其他案例的数据误算进来。同时补充了空设备列表的边界判断：如果当前案例下没有设备，则不能认为报价完成，而应标记为未完成。

抽象后的逻辑大致是：

1. 查询当前案例下所有设备
2. 如果设备列表为空，标记未完成
3. 查询当前案例下这些设备的报价记录
4. 按设备维度分组
5. 如果有报价记录的设备数量等于设备总数，标记完成
6. 否则标记未完成

除此之外，我还在几个关键接口后补充了校验调用，包括：

• 手动编辑并保存报价后
• 导入报价数据后
• 执行批量参数生成报价后

这样可以保证用户无论通过哪种方式修改报价数据，最终“是否完成基础报价”字段都能和实际数据保持一致。

这次修复让我意识到，状态字段不是简单地更新一个值，而是要站在业务流程角度去看：哪些操作会改变它依赖的数据，哪些入口需要重新触发判断。如果遗漏某个入口，就可能出现状态不一致的问题。

二、排查碳排放统计接口负数异常

下午主要排查的是一个数据分析接口问题。这个接口会返回总碳排放量、日均碳排放量、平均碳排放强度、碳排放量曲线和碳排放强度曲线。

问题现象比较奇怪：接口返回的碳排放量曲线和碳排放强度曲线每个点都是正数，但总碳排放量却是一个很大的负数。由于日均碳排放量和平均碳排放强度都依赖总碳排放量，所以这两个字段也跟着变成了负数。

我没有一开始就改代码，而是先对返回数据做拆解。按常理，如果碳排放曲线每个点都是正数，那么曲线求和后的总量也应该是正数。于是我先把曲线点位求和，发现结果确实是正数，说明曲线计算本身大概率没有问题。

继续看代码后，我发现接口里存在两套统计口径。

第一套是按碳排放量曲线逐点累加：

totalCarbon = sum(carbonCurve)

这一套结果是正数，并且和曲线展示一致。

但后面代码又把 totalCarbon 覆盖成了另一套结果：

totalCarbon = 算法结果表中的总碳排放量 + 联络线碳排放汇总

而当前数据中，算法结果表里的总碳排放量本身就是一个较大的负数，所以最终加上联络线碳排放汇总后，totalCarbon 仍然为负数。

因此异常链路可以总结为：

carbonCurve 每个点为正数
=> sum(carbonCurve) 为正数

但最终返回 totalCarbon 使用了另一套口径：
totalCarbon = algoTotalCarbon + totalTielineCarbon

其中 algoTotalCarbon 来自数据库算法结果字段
该字段当前值为较大负数
=> 最终 totalCarbon 为负数

日均碳排放量的计算逻辑是：

dailyCarbon = totalCarbon / 天数

所以 totalCarbon 为负时，dailyCarbon 也会变负。

平均碳排放强度的逻辑是：

carbonIntensity = totalCarbon / totalEnergy

由于 totalEnergy 是正数，totalCarbon 是负数，因此平均碳排放强度也变成负数。

同时，我也确认了为什么碳排放强度曲线仍然是正数：它不是用最终 totalCarbon 计算的，而是逐点用“当前点碳排放量 / 当前点电量”计算。由于每个点的碳排放量和电量都是正数，所以曲线结果正常。

也就是说，本次异常的核心不是所有碳排放计算都错了，而是曲线和汇总指标使用了不同统计口径。

三、没有贸然改代码，而是先整理计算链路

排查到这里后，其实已经能定位到负数主要来自算法结果表中的总碳排放量字段。但我没有直接把代码改成使用曲线求和值。

原因是我还不能确定原有设计意图。也许业务上要求总碳排放量必须使用算法结果表中的总量字段，也可能是历史代码遗留导致统计口径不一致，或者当前数据库中存在脏数据。

如果没有确认业务口径就直接修改，可能会影响其他功能。因此我把计算逻辑整理后发给组长，主要包括：

• 各返回字段之间的计算关系
• 曲线为什么是正数
• 总碳排放量为什么会变成负数
• 日均碳排放量和平均碳排放强度为什么跟着异常
• 当前代码中存在两套统计口径
• 建议后续确认是否统一为曲线求和口径

我的建议是：如果前端展示的碳排放量曲线是主要依据，那么总碳排放量、日均碳排放量和平均碳排放强度最好也和曲线保持同一统计口径。这样可以避免出现“曲线正常，但指标卡异常”的情况。

四、今天的收获

今天最大的困难其实是环境问题。下午服务器上的项目访问不稳定，接口调试和页面验证都受到了影响。实际开发中并不是所有时间都花在写代码上，环境、数据、权限和部署状态都会影响效率。

从技术上看，今天主要有两点收获。

第一，状态类字段的维护要关注完整链路。上午的 Bug 让我意识到，导入、编辑、批量生成等入口都会改变报价数据，因此状态校验必须覆盖所有相关入口，不能只处理某一个接口。

第二，统计类接口要特别注意数据口径。下午的问题表面上是总碳排放量为负，但拆开后发现曲线计算是正常的，真正异常的是最终汇总指标使用了另一套来源数据。