zhlifeiy · 工程笔记

组件提示上传成功，点击确定却发生 Java 堆溢出，问题藏在二次上传和 multipart 内存编码里。本文从异常栈还原链路，再用附件 ID 复用、磁盘中转和流式发送控制资源占用。

有索引的统计 SQL 也可能很慢。这次优化把两次全历史最新状态判断合并为一次窗口计算，生产只读对比快约 37.6 倍；真正难的是保留重复键、空时间和跨天在场的原有口径。

告警列表能显示数据，只是闭环的起点。把候选事件、规则判断、持久化通知、真实审批和统一入口接起来，还要处理事务时机、页内待办匹配以及不同角色的数据范围。

关闭 Source Map 不能让浏览器中的长期密钥变得安全。本文复盘一次 STOMP 鉴权改造：登录后签发短期票据、服务端兼容旧框架，再通过负向测试和密钥轮换完成上线闭环。

平台返回发送成功，并不代表设备数据已经同步成功。沿着命令、回程消息和时间窗口拆开排查，才能解释为什么定时任务恢复之后，历史记录仍然没有回来。

导读

给自己的开源小项目 Obsidian Mobile Companion（Android 端，GitHub 同步 Markdown 仓库）做了一天的体验升级：图片全屏查看器（双指缩放 + 双击放大 + 同目录滑动切换）、AI 生成的整套品牌素材、插画空态、LazyColumn 性能收尾。真正的硬骨头有两个：手势缩放与 Pager 翻页的事件争夺，以及一个中文用户名引发的 Gradle 灵异 bug。

导读

9 月 14 日接连猎杀三个”慢”：巡更任务分页 5 秒卡死（三层根因叠加）、统一通知列表线上 1s+（真凶不在 SQL 层）、动环 CO 查询 21 秒（203 万行全表扫描）。外加一个番外：停车位”视频预览按钮消失”，看起来像后端挂了，其实是前端 null.length 把请求拦在了发出之前。四个案子共用同一套方法论，文末汇总。

导读

一天之内把钉钉公告功能堆到第三层：P1 同步落库、P2 统一列表合并、P3 全员物化 + 站内信触达 + 每小时定时同步。三轮外部 review 抓出的问题全部核实属实并修复；然后是本次最有价值的部分——生产上线排障实录，八个坑每个都真实发生。文末附一份可复用的上线部署清单。

导读

评测 AI 编程 agent 的方式有很多，最狠的一种是：把一个真实功能从需求澄清到生产上线的完整一天交给它。本文以”访客设备列表接真实接口”为样本——这个任务罕见地覆盖了数据普查、方案对齐、全栈开发、多层验证、外部评审处置、合并推送、生产库操作、发布物料的完整生命周期，因此能比较全面地观察 agent 在真实工程项目里的协作表现。结论先行：适合做全周期工程协作者，但有三道人工关卡必须保留。

导读

一个纯 mock 的演示页面要接成真实接口。动手前先做数据普查——确认全系统真的没有访客设备表；然后设计”实体 + 事件”两张新表，用 9+1 的造数结构让”在线时长”不需要定时任务就能自然增长；最后外部 review 抓出四个 P2，其中一个 OGNL Date 坑在老代码里还埋着同款雷。