AI开发牧安 · 第4期 那个后台是怎么堆出来的

第3期聊完选型，这期讲"怎么堆出一个能登录、有权限、能收数据的后台"。

WN101 这个后台，说穿了就是从三块最朴素的东西搭起来的：一个能登录的网页、一套能认人的权限、一个能装东西的库。没有微服务，没有网关，没有那堆听起来高级的词。就是先让人进得来，进来了只能看该看的，然后东西能存住。

先搭个壳子

最早那版是顶部一排导航，点来点去不顺手。后来改成左侧一棵固定菜单——展得开 220 像素，收起来 60 像素只留图标，鼠标移上去能看名字。顶上一条工具栏，放标题和切主题的按钮。盯一天屏幕，这个布局比满屏标签省心。

图片

上图仅为示意，非真实环境。

深浅两套主题，选了存浏览器本地，刷新不丢。菜单按业务分了组：运营总览、安全检查、监测中心、安全工具、系统管理。这套东西看着简单，其实是我盯屏幕时间最长的一版——颜色、间距、圆角、悬停动画，一个个调。间距按 4 像素走基准，圆角分四档，过渡统一 0.15 秒，就图个顺眼不累。

再装道门

壳子有了，得有门。登录走 `POST /api/auth/login`，用户名密码对上，后端用 `secrets.token_urlsafe` 随机搓一个 token 回来，前端每次请求都带着 `Authorization: Bearer xxx`，后端中间件验。token 塞在 `auth_tokens` 表里，七天过期。密码不存明文，是 SHA-256 哈希。

图片

这道门的意义不只是"不让外人进"。更关键的是，进来的是谁、能看什么，后面得接得上。单有 token 不够，得有人和权的那层关系。

墙是客户隔出来的

由于做的是多客户运营——一个团队管几十家客户，A 的客户绝不能让 B 看见。那时候用两张表：`users` 放账号和角色，`user_customers` 把账号和客户 ID 绑一块（多对多）。角色就两个：admin 看全部，user 只看被授权的那几家。admin 锁死，不能删不能禁用。查询的时候按当前账号能看的客户 ID 去过滤，越界的查不出来。

图片

这套隔离是单库里的隔离——所有客户数据躺在同一个 SQLite 里，靠 `user_customers` 这张关系表划边界。当时觉得够用，管几十家客户没问题。后面做三级架构时才发现，单库混着客户数据，上了规模就是个坑（这个第2期聊过，不重复）。但那会儿，它确实让我一个后台兜住了最早那批客户。

 堆壳子的过程没那么顺

说"搭起来"三个字轻松，真干的时候全是坑。

有一回改着改着，整个 `app.js` 直接挂了——页面白屏，所有按钮失灵。查了半天才发现是 `addDiscoveredAssets` 这个函数，外层写了 `try` 却没写 `catch`，JS 语法要求 try 必须跟 catch 或 finally，于是整个文件解析失败，里面所有函数定义全废了。最后靠数括号（开 328、闭 328 才对上）才定位到。改完还得强制刷新，不然浏览器还缓存着坏的旧文件。

还有按钮点了没反应。原因是事件绑定写在了 `window.onload` 外面，DOM 还没出来就去 `getElementById`，拿到 `null` 调 `addEventListener`，直接抛错把后面全中断了。挪进 `window.onload`、加个判空就好了。

最磨人的是缓存。改完 CSS、JS，刷新页面纹丝不动——浏览器把旧的缓存住了。得 `Ctrl+Shift+R` 强刷，或者给文件加 `?v=版本号` 逼它重新加载。在家一个人调前端，这些破事全得自己扛，没人帮你分一眼控制台。

 壳、门、墙齐了

到这步，WN101 算是个能跑的后台了：有界面、能登录、人分了角色、客户隔了边界、数据落进 SQLite。但它还缺最关键的一道——客户现场的东西怎么进得来？靠人手动填肯定不行，得让机器自己报。

下期聊数据接入层：Webhook 双认证（Bearer + HMAC 签名）、Agent 怎么注册和心跳、还有第一台真实探针 `192.168.58.142` 怎么落地的。那才是这个后台真正"活"起来的时刻。

本系列记录牧安平台从 0 到 1 的开发过程，一个待业在家的网安老兵边做边想。

上期： 《技术选型》；下期预告：《 数据是怎么自己进来的》。