最近一段时间，我处理了不少物流系统里的小问题。它们单独看都不算复杂，但麻烦的地方在于：同一个页面、状态、接口、数据库字段，可能会被多个业务步骤同时使用。
这篇记录几个最近工作里比较典型的 Bug 修改。
1. 费用详情不是所有状态都能编辑
其中一个问题出现在费用详情页。预期规则很明确：只有费用状态是 NEW 或 REJECTED 时，才允许编辑费用详情。
实际情况是，某些后续状态的数据，比如 RELEASED_FINANCE，仍然可以打开编辑框。这就有风险，因为费用一旦进入财务流程，再被用户修改，后面的确认、对账、接口同步都可能出问题。
这个修改不能只隐藏按钮。我需要继续看前端打开编辑框的事件链路，因为有些操作不是单纯靠按钮控制，而是通过表格事件触发。
最后规则收敛成几条：
- 打开编辑框前先判断当前费用状态。
- 只允许
NEW和REJECTED编辑。 - 财务、确认后的状态直接禁止打开编辑框。
- 判断逻辑尽量放在统一入口，避免以后按钮改动后绕过校验。
这类问题如果只测按钮是否隐藏，很容易漏掉。真正要测的是：用户还能不能通过其他页面动作打开编辑框。
2. 批量接口允许部分成功
另一个修改是接口 /lrms/vehicle 需要支持部分成功。旧逻辑是只要某一条数据校验或处理失败，整个请求就会失败。
但对批量数据来说，这种处理方式不够实用。一条车辆数据有问题，不应该影响其他正确的数据入库或更新。调用方更需要知道：哪些成功了，哪些失败了，失败原因是什么。
实现方向是：
- 按记录逐条处理。
- 单条异常只影响当前记录，不中断整个批次。
- 响应里返回每条记录的成功或失败状态。
- 失败信息要保留到能让调用方定位和修正数据。
这种接口不能只看 HTTP 状态码。HTTP 200 只能说明请求完成了，真正的业务结果要看响应体里每一条数据的处理结果。
3. 净重和体积优先从包装配置取值
还有一个问题是重量和体积计算。接口进来的订单和手工创建的 work order，都需要在有包装单位配置时，优先使用包装单位里的净重和体积。
原来的逻辑可能太早回退到 SKU 基础字段。这样当包装单位本身配置了净重或体积时，计算出来的总净重、总体积就不对。
调整后的规则是：
- 毛重仍然保持原来的 SKU 取值逻辑。
- 净重和体积先查包装关系配置。
- 有包装单位净重时，使用
数量 * 包装单位净重。 - 有包装单位体积时，使用
数量 * 包装单位体积。 - 包装数据缺失时，才回退到 SKU 基础字段。
这个问题不能只改手工创建页面。因为订单也可能从接口进来，所以接口导入和前端录入都要一起检查，否则还是会出现同一类数据计算不一致的问题。
4. 外部接口错误不能被吞掉
还有一些问题和 SAP、OpenAPI 这类外部接口有关。常见情况是，下游系统已经返回了有用的错误信息，但页面上只显示一个很笼统的失败提示。
这样排查会变慢。用户和开发都需要看到原始错误里的关键信息，比如连接失败、数据关系无效、SAP 单号缺失等。
这次处理的方向是：不要把外部异常统一替换成模糊提示，而是把可用的异常信息继续传到响应里。
这不是说要暴露敏感信息，而是要保留能帮助定位问题的部分。至少要能判断这是数据问题、网络问题、映射问题，还是外部系统状态问题。
这次修改的收获
这几个 Bug 给我的提醒比较直接：
- 不要只相信按钮状态，要检查真正的事件入口。
- 批量接口如果要求部分成功，就必须返回每条记录的处理结果。
- 手工页面和接口导入如果共用业务规则，计算逻辑必须对齐。
- 外部接口错误不要被统一吞成一句无意义的失败提示。
- 一个小的状态判断，可能会影响财务、调度、计费和接口同步。
多数 Bug 修改不是写多复杂的代码，而是找到系统到底在哪一步放过了错误状态、错误数值，或者丢掉了关键错误信息。
我后面需要继续强化的是：先看数据，再跟调用链，尽量只改最小安全范围，最后从用户真实操作路径验证结果，而不是只看代码分支是否走通。