2025 年 6 月，我在掘金写过一篇《为什么我选择用 Rust 构建全栈后台管理系统？》。那时我刚从 Tauri 进入 Rust 后端，主要靠 AI 边学边做，rustzen-admin 已经有了登录、用户、角色和权限等基础功能。
一年后再看，变化不只是多了多少页面。项目从一套能够运行的前后端代码，逐渐变成了一个需要同时考虑权限、存储、运行目录和部署交付的工程模板。很多重要调整也不是第一版设计出来的，而是在持续开发、重构和实际使用中慢慢明确的。
现在的 rustzen-admin
目前的 rustzen-admin 是一个开源的 Web/Rust 管理系统工程模板。后端使用 Axum，前端使用 React，SQLite 是默认存储。后端应用、前端应用、共享 Rust crate、数据库迁移和部署文件都放在同一个 monorepo 中。
项目已经具备用户、角色、菜单和字典管理，登录认证、接口和按钮权限，操作与登录日志，仪表盘、定时任务、文件上传，以及服务端和前端发布包管理。数据库、上传文件和日志从统一的运行根目录派生，仓库里也提供了服务安装、目录初始化和发布检查所需的内容。
这些功能已经能够组成一条完整的管理链路。但功能存在，不代表边界已经稳定。一年里的很多工作，实际都在解决同一件事：当项目继续增加功能时，怎样避免权限、数据和部署方式重新变得混乱。
权限和存储逐渐收敛
早期的提交集中在登录、用户、角色、菜单、字典和日志等基础模块。功能增加以后，权限如果只靠前端隐藏菜单和按钮，很快就会失去约束。因此现在由后端接口声明并校验所需能力，前端根据当前用户权限决定展示什么，两边使用同一套明确的权限代码。
系统内置了 owner、admin 和 viewer 三种角色。owner 是唯一拥有全部能力的角色，也只有 owner 用户能够继续分配这个角色；admin 可以管理用户、执行任务和导出日志，但部署管理只允许查看；viewer 只保留列表、仪表盘和部署版本查看等读取能力。内置角色由服务端同步并保护，普通角色则继续通过明确选择权限来扩展。
这套设计并不复杂，重点是把默认边界说清楚：谁能控制整个系统，谁负责日常管理，谁只能查看。对工程模板来说，可扩展的权限边界比预置多少菜单更重要。
存储也经历过一次取舍。项目最初使用 PostgreSQL，后来调整为 SQLite 优先。这样做降低了本地启动和小规模部署的成本，但原来由外部数据库承担的部分责任也回到了应用本身。数据库文件放在哪里、迁移如何管理、运行数据怎样清理，都需要成为项目内的明确约定。
目录重构要落到运行和部署
随着功能增加，我开始重新考虑目录应该表达什么。如果后端、前端、共享能力和部署文件继续混在一起，每次调整都会同时影响多个入口，也很难判断一段代码应该由谁维护。最后的方案是按职责拆分：apps/ 放应用，crates/ 放共享能力，deploy/ 管理部署资产，docs/ 保留工程说明。
这次调整的目标不只是让目录看起来整齐。API 路径、前端请求、数据库迁移、构建命令、运行目录和文档都需要跟着新的边界重新整理，并重新走通开发、构建、启动和部署。数据库、日志、上传文件和发布产物也因此有了统一的运行位置。
部署方式同样调整过。项目曾尝试把前端静态文件嵌入服务端二进制，后来改为分别管理服务端和前端产物。现在发布包会记录版本、架构、文件大小和校验信息，并支持在管理页面上传和切换；仓库里也补充了 systemd 服务、运行目录初始化和发布体积检查。部署不再只是仓库外的一段操作说明，而是项目需要长期维护的一部分。
前端改造还在继续
前端的工作重点已经从“把页面做出来”转向建立一套可以持续扩展的页面结构。路由迁移到 TanStack Router 后，登录和认证入口重新进行了整理；管理页面则使用 shadcn 逐步重建，把原来分散在各个页面里的布局、表格、分页、表单和确认交互收进共享组件。
这轮改造不只是替换组件样式。我更希望先把路由、权限和公共组件的边界理清，减少业务页面重复维护相同代码。接下来会继续完成现有管理页面的改造，再以这套结构接入新的业务模块。
回顾这些变化，我最后更倾向于先维护一条清楚的默认路径：Axum 后端、React 管理端、SQLite 默认存储、统一运行目录，以及可安装和切换的发布产物。项目更适合单机或小规模部署；如果需要复杂数据库集群、完整容器编排或多租户能力，仍然需要根据实际场景继续设计。
接下来要做的事
后续计划主要有三项：
- 完成当前的前端改造，统一页面结构和公共组件；
- 完善日志、上传文件、定时任务和部署版本的保留与清理机制；
- 验证服务器监控、埋点等新能力，再选择适合的部分接入。
这些方向也来自我之前的实际运行经验。我曾经把监控和埋点相关系统部署在约 100 台服务器上，运行中主要遇到三类问题：采集和聚合阶段存在较多临时数据和重复解析，同时出现过进程内存占用偏高；原始指标和事件持续写入，存储空间不断增长；容器环境里的 overlay、临时挂载、重复挂载点和虚拟网卡会造成节点指标失真。
后续会先优化采集和聚合过程，减少临时集合与重复解析，并继续观察这些调整对内存占用的影响；为指标、事件和运行日志建立明确的保留周期与分批清理机制，同时处理 SQLite 空间回收；节点采集则需要过滤 Docker、Kubernetes 等容器挂载和虚拟网卡，并按挂载点去重，提高磁盘和网络数据的准确性。这些优化会先在实际运行中验证，再把适合管理系统的部分逐步接入 rustzen-admin。
一年前，我更关心的是，能不能借助 AI 用 Rust 把一个完整后台做出来。现在，具体实施和验证更多交给 AI，我把精力放在决定做什么、为什么做，以及项目的边界应该收在哪里。
这样的协作提高了实现速度，也拓展了我能处理的问题范围，但新的难点也随之出现：怎样把目标、约束和验收标准说清楚，让 AI 产出的代码可维护、功能可验证、性能有数据支撑。下一阶段，我会继续完善这套协作方式——由我负责方向、取舍和最终判断，AI 负责实施、测试和性能验证，在提高效率的同时，让 rustzen-admin 的架构和工程边界继续收敛。