zhlifeiy · 工程笔记

园区平台的信息发布模块，同一天在同一个接口上连续爆出两个不同的 500：下午五点半一个 NullPointerException，二十分钟后一个 DateTimeParseException。表面是两个不相干的异常，根因却是同一个模式——前端把非法值带进了请求体，后端在关键路径上既没有校验也没有空值保护，@Transactional 回滚，数据未落库。这篇记录两个 bug 的完整触发链，以及那条最值得记住的结论：前端校验的对象，和最终提交的对象，根本不是同一个。

告警有个期限，到期没人理，级别就往上抬——需求一句话就说完了。但落地时它分裂成两条业务线：人工确认线的期限在告警侧（告警产生时刻 + N 分钟），自动工单线的期限在 BPM 侧（审批节点配置的处理时限）。两版方案迭代下来，最终的形态是一条 UPDATE 语句覆盖两条线，而中间踩掉的几个坑，比 SQL 本身更值得记录。

把告警系统和 BPM 工单打通，听起来是”调一个发起流程的接口”就能做完的事。真正做起来才发现，难点从来不在发起，而在失败的那一瞬间：远程流程已经发起成功、本地事务却回滚了，那条没有告警指向的孤儿工单谁来收？本文记录这次改造里三个相互咬合的设计——契约、补偿、防线——以及一个”什么都没发生”的典型 bug。

园区平台的消防设备地图功能上线那天，楼层平面图一张也显示不出来。从 dev 联调一路追到生产 Nginx，最后发现这不是一个 bug，而是三层断点叠在一起：库表迁移没跑、前端 env 缺配置、Nginx 缺路由。任何一层单独修好，页面依然是坏的——这大概是”新功能第一次把文件服务暴露到浏览器侧”时最典型的事故形态。

导读

把原有 PC 站内通知扩展到钉钉和短信，表面上只是根据类型多调用两个接口。真正落地时却牵出四个问题：双通道重复查询用户、钉钉 Token 每次发送都重新获取、外部通道失败可能拖慢告警事务，以及“代码接入”很容易被误写成“线上已经打通”。

这篇记录一次多通道通知链路的 review：如何把共享前缀提到路由层、用进程内缓存控制 Token 请求、让各通道互不拖累，并诚实区分钉钉实测成功与短信外部环境仍阻塞的边界。

导读

一个表单页面同时编辑“监控任务”和“告警规则”，看起来只需要一个保存按钮，后端却分属两个服务，无法共享本地事务。真正危险的不是接口报错，而是第一步成功、第二步失败后留下一个已经启用却没有专属规则的任务。

这篇记录最终落地的保存协议：前端预生成业务 ID，先以禁用状态创建任务，再幂等保存规则，最后才启用任务。它没有引入分布式事务框架，但把失败窗口收敛成了可重试、不会误触发的安全状态。

导读

给 AI 告警弹窗加上接收人定向后，暴露出一个结构性问题：告警规则是「类型级」共享的，同类型的所有监控任务共用一条规则，A 任务改接收人会把 B 任务的也改掉。这次把规则挂到任务级，语义是「任务优先、共享兜底」。改造中确认了三条反直觉的约束（禁用不回退、只认 ‘0’、共享查询显式隔离），顺手修了一个 threshold_status 整列写不进库的存量 bug，全部由单测 + 真实 SQL + 接口级 E2E 验证。

导读

给告警规则任务级化改造做接口级 E2E 时，踩了一圈环境坑——服务在 JDK 17 下「能起端口、能收请求」，错误全在运行期深处才爆；Git Bash 里 export PATH 是个假动作；curl 带中文直接乱码。每个坑都有实锤报错。这篇把过程沉淀成配方，下次本地起服务测接口照抄即可。

用户抛了一个看起来简单的问题：显示屏推送代码是不是没问题？线上能顺利保存「推送显示屏」的告警配置，但不确定真实告警触发时推不推得出去。排查后结论有点意外：这条链路从没真正跑过。更值得记录的不是结论本身，而是排查过程中我做的四次错误推断——每一次都被事实打脸。这篇诚实复盘整个过程。

园区安防平台有一类需求：AI 摄像头检测到人员越界，前端要能在右下角弹一个带实时视频的告警卡片。旧版代码里这套弹窗是「半幅骨架」——后端发送链路还在，但前端订阅早就下架了。这两天分两轮把它补成了完整闭环：第一轮让它「能弹出来、能播视频」，第二轮加上「只弹给指定的人」和「用户能在卡片里录一段、截一张」。这篇记录链路设计、几个关键决策，还有联调时踩的坑。