从表格到管理系统：别先写页面，先补齐权限、流程和审计

"把这几张 Excel 做成网页"听起来像一个明确需求，实际往往只描述了界面，没有描述系统。

表格真正承载的可能是客户、订单、审批和对账；微信群承载的则是催办、授权与异常处理。开发团队如果直接从字段和页面开工，很容易得到一个在线版表格：能增删改查，却仍然说不清谁能改、状态怎么走、失败如何恢复。

我的判断边界是：Excel 并没有过时。Microsoft 365 已支持共同编辑和版本历史。只有当协作复杂度、权限风险、流程稳定度、错误成本或数据复用价值开始上升时，管理系统才可能比改进表格更划算。

判断是否立项，可以看 7 类信号：

这不是一个"命中三项就开发"的统计阈值。更实用的办法是分别评估发生频率和影响程度。低频、低影响问题先改善模板和责任分工；高频但流程尚未稳定的问题先做流程梳理或低代码试验；高频、高影响且规则稳定，才适合进入定制系统评估。

先写出"永远不允许发生什么"：关闭的工单不能再次指派，跨租户角色不能分配，停用用户不能继续持有有效会话。它们应该在服务端统一执行，关键关联再由数据库约束兜底。

角色是能力集合，权限是更细粒度的动作。页面、菜单、API 只是这些能力的不同入口。如果把授权写成页面里的用户名判断，角色一变化，规则就会散落到各处。

本次核验的 ruyi_admin_gold 身份管理实现中，应用服务按租户约束用户和角色读写，角色分配只接受同租户角色；数据库迁移又为用户角色关系增加租户列和两组复合外键，并约束租户内角色代码唯一。

应用层给出业务语义，数据库层守住不可破坏的结构边界。只做其中一层，都容易在批处理、维护脚本或后续功能中留下绕过路径。

成功变更与关键审计记录需要保持一致。核验实现把身份管理变更与审计写入放在同一数据库事务中；用户停用和密码重置还会撤销有效会话。否则，业务已经回滚而日志显示成功，或密码已重置但旧会话仍能调用接口，都会形成新的风险。

第一版最好选择一个纵向切片，而不是铺开十几个模块。例如只实现"采购申请从创建到审批完成"：

数据模型至少要表达实体、状态、归属范围、版本或并发控制字段，以及必要的唯一约束。授权判断应位于应用服务或统一策略层；前端隐藏按钮只负责体验，不能作为安全边界。

迁移也要进入设计：先固定字段口径，抽取小批样本，清洗并导入测试环境，再回读核对数量、唯一键、状态和关键金额。上线前写清失败回退点、旧表停止写入时间和归档负责人。

本文引用的项目事实来自固定提交和文件哈希，而不是根据界面截图推断：

这些证据证明的是一种可复用的边界设计，不代表所有管理系统都必须采用相同技术栈。单组织、低风险工具可以更轻；涉及多租户、资金或敏感数据时，还需要更完整的威胁建模、备份恢复和合规评估。

同样，不要把测试通过等同于生产可用。上线验收还应覆盖真实身份源、并发、备份恢复、监控告警和回滚演练。

从表格到管理系统，最难的不是把单元格变成输入框，而是把隐含规则变成可执行、可拒绝、可追溯、可验收的系统边界。

你做过的项目里，最容易被低估的是权限、迁移、审计，还是失败恢复？欢迎补充你的取舍和踩坑。