zhlifeiy · 工程笔记

给园区监控系统加录像/截图线上存储：后端设计与踩坑记录

2026-07-29T08:30:00.000Z

园区监控平台里，用户看实时视频时的截图和录像，原本是浏览器直接下载到本地。这次把它改成上传线上存储，并补齐了分页列表、查看、改名、批量删除和审计日志。这篇复盘记录几个关键的设计决策，以及过程中踩到的五个真实的坑——分页插件的 NULL 参数、通用 mapper 的 OGNL 陷阱、单测测不到的 XML 语法错误、被 distinct 折叠的测试数据，还有 PowerShell 拼 URL 的变量名陷阱。

给 Hexo 博客加一个 AI 助手：MiniMax + Cloudflare Workers 实战

2026-07-26T05:10:10.000Z

我的博客已经有项目分类、公开简历和本地搜索，但读者仍然要自己翻文章。于是我做了一个“问博客”助手：输入问题，它先从博客中找相关文章，再把少量公开片段交给 MiniMax 生成回答，并附上来源链接。

这篇记录从前端检索、Cloudflare Worker、MiniMax-M3 接入到安全部署的完整过程，也会说明它为什么还不算完整的向量 RAG，以及我准备怎样用最小成本升级。

四道内部 CTF 的共同根因：API/Web 鉴权割裂与 RBAC 继承风险

2026-07-21T12:00:00.000Z

一次经过授权的内部 CTF 复盘：四道题看似考接口绕过、数据越权和角色提权，根因却集中在鉴权策略割裂、返回字段失控与角色继承边界缺失。

在 16G 内存的 Windows 本机跑通 shopkeeper-agent：13 个坑的完整排障笔记

2026-07-18T13:30:00.000Z

从零在 Windows 11 + 16G 内存下跑通电商问数项目 shopkeeper-agent 的完整排障笔记，覆盖 Python 环境、LLM 接入、Embedding、Docker、中间件、后端启动六大环节共 13 个真实坑。

一次干净的「放宽约束」重构：让公司楼层配置跨园区

2026-07-18T13:30:00.000Z

公司默认可见楼层配置（/orgFloorConfig/{orgId} 查询、POST /orgFloorConfig 保存）最初的语义是「限当前园区」——超管在 A 园区，只能给 A 内的公司配 A 的楼层。本次把它放宽为「跨园区绑定」：一个公司可以同时绑多个园区的楼层。改动只动 6 个文件 +70/-23，但牵住了查询、保存、校验三个「按当前园区」硬编码点的同步改造，是放宽约束类重构的一个干净样本。

O(N×M) 拍平成 O(N+M)：反查表如何把楼层摄像头计数从慢路径救回来

2026-07-17T11:00:00.000Z

「勾这个楼层到底覆盖几个摄像头」——超管在配置页的盲勾体验必须解决。后端用反查表把 O(N×M) 拍平成 O(N+M)，前端零计算渲染，6 个单测全绿。本文把这个看起来简单的功能拆开讲。

氚云访客历史同步漏数据？分页方式、日期语义、头像容错三处全改

2026-07-14T12:44:00.000Z

氚云访客历史同步漏数据不是网络问题，而是分页方式、日期语义、头像容错三处都写错了。本文把三个根因、四个修复点、服务器验证步骤完整拆开，让你下次遇到第三方同步漏数据时能直接套用排查思路。

一行 parkId 改不出越权：契约测试如何锁死 Token 身份来源

2026-07-13T03:00:00.000Z

多园区切换接口能不能被前端伪造身份？改一行 parkId 就能越权吗？本文用 4 个测试用例 + 1 次反向变异验证，证明 userParkSwitch 的身份来源、授权顺序、Redis 更新顺序已被源码契约测试锁死。

多园区改造测试全景：从登录到业务隔离的 7 大模块验证清单

2026-07-08T09:15:00.000Z

多园区改造不是改几个字段那么简单。登录态、菜单、角色、同步链路、业务数据、回归兼容——任何一个模块漏测，都可能在生产里埋雷。本文把改造测试要覆盖的 7 大模块完整拆开。

园区切换不生效？Redis DB 不一致这个坑我替你踩过了

2026-07-07T01:50:00.000Z

dev 环境切园区后 /user/info 仍是旧园区，访客预约列表也不刷新。问题不在业务代码，而在 admin-service 和 gateway 写入了不同 Redis DB——这次把排障链路完整记录下来。

钉钉同步性能优化（异步化+批量化）+ 头像回填 CDN 解析失败

2026-06-25T10:00:00.000Z

导读

钉钉同步两个故事：(1) 15000+ 用户同步时 HTTP 超时——根因是 toUpdateUsers 循环内 3 次 DB 查询每人 = 46000 次 SQL round-trip 在一个事务内串行执行，两步优化：异步化（HTTP 立即返回”已受理”，后台静默执行）+ 批量化（循环前 IN 批量预加载到 Map，循环内 O(1) 查 Map），计划阶段就识别出 4 个潜在 bug（路径双重前缀、BaseResultMap 错映射、dirty-check 破坏恢复语义、peek 污染原始 DB 状态）。(2) 头像回填接口返回 200 但成功数始终为 0——admin 服务器在内网，DNS 无法解析钉钉 CDN 域名 static-legacy.dingtalk.com，所有用户全部被静默跳过。

PDEPARTS 废弃 + 头像同步修复 + 用户查询回归：递归 CTE 上溯

2026-06-23T10:00:00.000Z

导读

6/22 暴露的 PDEPARTS 下线问题，今天给出完整修复：废弃所有依赖 PDEPARTS 的解析，改用部门 UUID 沿 sys_organization.parent_id 递归上溯查 sys_park_organization 桥表（MySQL 8 CTE）。一个 commit 改了 8 个文件、+167/-33，把昨天识别出的 4 个 Bug 全部修完。同时顺手把头像同步 bug（setFacePic 误写为 setFacePicAuditStatus）修了，并补充 face_pic='2' 历史脏数据的处理策略。

PDEPARTS 字段下线与钉钉同步真实格式链路测试报告

2026-06-22T11:00:00.000Z

导读

今天捅了两个马蜂窝：中台 Dataphin 下线了 PDEPARTS 字段，导致所有依赖该字段解析公司归属的 Java 逻辑静默失效（getCompanyIdFromPDeparts / getDepartmentAsList 返回 null），1542 个 Ding 用户 100% 缺 sys_user_park；用真实格式跑 12 个端到端测试用例，又挖出 4 个新 bug（增量更新取消删除标记失效、园区链路仍依赖 PDEPARTS、pass_user 链路同样依赖 PDEPARTS、部门 vs 公司数据源不一致）。修复方案是改用部门 UUID 沿 parent_id 递归上溯查桥表（CTE），以及补回 synSysUserToPassUser ADD 分支漏设的 distSyncStatus。

dist_sync 分支集成测试报告：9 项功能 12 个用例全过

2026-06-16T05:00:00.000Z

导读

dist_sync 分支自 6/10 起的所有改动（19 个提交 + 6/16 未提交的”部门+园区更新”），今天做端到端集成测试。9 项功能 12 个用例全过，未发现阻断性缺陷。1 处 dist_sync_status 表现差异已查明为下游消费者正常行为（非 bug）。这篇不是技术深挖，是测试方法 + DB 证据 + 关键发现的完整记录，适合需要做类似集成测试的同行参考。

pass_user 字段同步 + 人员列表联动 + 代码审查：折中方案与前端 import 来源踩坑

2026-06-15T08:00:00.000Z

导读

今天三个主题：钉钉同步补 pass_user 的手机号和部门（折中方案）、人员列表页面部门下拉按园区联动（前端 import 来源同名坑）、代码审查记录（已合并改动）。其中最值得记录的是折中方案的取舍——为什么”换部门同步”主动放弃，以及前端 import 同名函数指向不同后端接口这种隐蔽问题。

pass_user 死亡覆盖链与 spec 错误判断：从集成测试挖出 421 条脏数据

2026-06-12T10:00:00.000Z

导读

6/11 实现的”钉钉同步触发 pass_user 同步”功能本身端到端跑通，但暴露出 6/11 spec 文档第 46 行的一个事实错误判断：把 PassUserServiceImpl.synSysUserToPassUser() 里的 setParkId(DEFAULT_PARK_ID) 误判为”无效死代码”。实际是有效过滤。更糟的是下午挖出了真正的死亡覆盖链：admin 端 UserMapperExt.xml 的 listByConditionExt SQL 没 select urp.park_id 列，导致 user.getParkId() 永远是 NULL，421 条 pass_user.park_id 全被污染成 NULL。

钉钉同步写 sys_user_park + 园区绑定一级公司：从功能到 OGNL 经典踩坑

2026-06-11T12:00:00.000Z

导读

今天一口气做了 2 个 feature + 1 个构建命令摸清：钉钉同步补 sys_user_park 占位记录、园区绑定一级公司（顶级 org + 互斥）、admin-service 打包 fat jar。feature 走的是 spec-first + subagent-driven，3 轮 spec review + 3 轮 code review。但 06-11 集成测试第一次就跑出 500——saveCompanyBind 调 updateParkOrganization 时，generic mapper 对 Date 字段 OGNL 求值崩了。**1 行 fix：删掉多余的 WebExtUtils.iniCreate(model);**。这条经验已经写进全局 CLAUDE.md。

登录 token 补齐与项目改动全量汇总

2026-06-10T04:00:00.000Z

导读

链路通了，admin 也起来了，但登录返回的响应没有 token——因为 token 是 Gateway 加的，不是 admin 加的。本篇解决：登录 token 补齐 + Nacos 分组统一 + admin 注册 Nacos + 980.sql 数据导入，以及一份完整的项目改动清单（5 个我们改的代码文件 + 3 个 dist_sync 分支已有的改动）。

6 个启动连环坑：从 MySQL 用户到前端 401 的完整链路打通

2026-06-09T14:00:00.000Z

导读

编译跑绿后，启动链路又冒出 6 个连环坑：MySQL 没 building_* 用户、property-service 写死内网 IP、admin 种子用户密码是 SHA512×2、is_enable=1 居然是禁用、gateway 报 JWT NPE、前端访问报 401。本篇一次性梳理这 6 个坑的根因、修复方案、排查顺序，以及哪些是”反直觉的项目约定”。

接手烂尾的 Spring Cloud 微服务项目：从零搭建 26 模块编译环境

2026-06-09T10:00:00.000Z

导读

接手一个停更 2 年的 Spring Cloud Alibaba 微服务项目，13 个业务服务、11 个独立数据库、26 个 Maven 模块，本地 Maven 仓库空空如也，mvn compile 一跑就是红海一片。这篇记录我从零搭建编译环境的完整过程，包括 Maven 配置重写、私有依赖安装、22 个 SNAPSHOT jar 的手工恢复，以及最终 26 模块 BUILD SUCCESS 的关键命令。