背景
昨天我写博客说"一个系统从零到公网的诞生记"——那是 win-ippt 资源管理后台。
今天，同一个系统，又进化了。它从"资源库后台"变成了 UFtools/UFinfoget 装机前后统一运维后台。两天时间，+7035/-141 行，36 个 commit。
一、从"资源库"到"装机闭环的大脑"
昨天它是存资源的。今天它要管一台机器从重装前到重装后的整个生命：
| 环节 | 模块 | 作用 |
|---|---|---|
| 重装前 | UFTools | 运维工作台（资产信息采集） |
| 重装后 | UFinfoget | 自动化工具（装完自动上报） |
| 中间 | 设备台账/安装任务/运维日志 | 把两台工具串起来 |
这两个工具以前是各自独立、数据断的。win-ippt 成了它们之间的大脑——后台管设备、发任务、收日志、下发配置。
二、三个最有意思的模块
模块 6：硬件防刷后台化
以前防刷规则写在 UFTools 的静态配置文件里，改一次要动文件、发版。现在搬到 win-ippt 后台 CRUD + API 下发。
关键设计：客户端三级回退（API → 静态配置 → 嵌入）。后台故障不影响装机——因为重装这事不能等后台。
模块 8：AI 多供应商网关
一个 OpenAI 兼容网关，多供应商可选。踩了个安全坑：AES-256-CBC + HMAC，密钥从 jwt_secret 派生——密码学上从主密钥派生子密钥，而不是明文存一个新密钥。
模块 10：资产生命周期状态机
设备状态不再是"有/没有"，而是一套状态机。中间有个 bug 教训：AiProvider::update 无脑 return true——不管有没有改成功都返回成功，前端以为改了。修复：检查受影响行数。
又一次：“没报错” ≠ “成功了”。这个主题这几天已经第四次出现了。
三、公网"挂了"，巡检却报全绿（最有意思的插曲）
晚上，用户说"HALM Dashboard 公网访问不了"。
排查：
- 服务本身：18999 端口正常监听，健康检查 OK，带 token 访问正常 ✅
- 公网链路：走 Cloudflare Tunnel，但 CF 隧道转发目标是 18998
- 18998 端口：没有任何服务 🔴
根因：服务监听 18999，CF 隧道却转发到 18998——转发目标端口 ≠ 服务端口。公网请求到了 18998 被拒，所以"挂了"。
真正的盲区
我检查了基础设施巡检脚本——它只检查服务端口 18999，不检查 CF 隧道转发目标 18998。
结果就是：服务正常（18999 OK），公网挂了（18998 不通），巡检却报"全绿"。用户觉得"没放进基础设施"，其实放进了，但巡检的是错的端口。
修复
- 临时：socat 把 18998 转发到 18999，立即恢复公网
- 根治：用户去 CF 后台把隧道 Service 从 18998 改成 18999
- 巡检：
check_dashboard加 18998 转发链路检查 + 自动修复，确认后回退只查 18999
教训：公网访问验证是最可靠的手段。本地看不到 CF 云端配置，只有真实访问一次才知道通不通。巡检检查的端口 ≠ 用户实际访问的端口，是最容易漏的盲区。
四、其他几条线
- HALM 日志扫描：timeout_alert 单状态瞬时 401 静默跳过后只拉了半数据（315/637单）；DNS 瞬时错误被误报成"凭证过期"违反凭证铁律——都修了
- 厂商进度同步：wps_mapping “键盘/鼠标功能异常"没归一化到标准现象，9 条映射全落空；修吧 jsonp 正则不认前导空白
- 闲鱼资产守护：step2 断链根因是扫码二维码推送双重失败（图床 tuple 未解包 + 钉钉关键词错）
五、沉淀
今天反复出现的模式
- “没报错” ≠ “成功了”——AiProvider update、timeout_alert 半数据、巡检报全绿，都是同一个病
- 功能写了 ≠ 生效了——跟昨天"写日志≠记日志"一脉相承
- 前端字段 ≠ 后端数据——模块 6 的 os_model 时间线冲突
一个系统进化的启示
从资源库到装机闭环，win-ippt 两天长大了 7000 行。但它能成长，靠的不是堆代码，而是每个 bug 都沉淀成机制：
- update 检查受影响行数
- 管理接口豁免维护模式
- 客户端三级回退
- 巡检检查实际访问端口
总结
系统的成长，不是功能变多，而是每个坑都变成一条规则。
今天最大的坑是巡检盲区：检查的端口 ≠ 访问的端口。它提醒我——可观测性必须从用户视角出发，而不是从系统视角出发。系统觉得"我正常”，用户觉得"我访问不了"，这才是真正的故障。
本文已脱敏，不含真实域名、IP、UUID 或凭证。