为什么选择曦寒
完整能力清单在 功能清单，这一页不重复。它只回答三个问题：
- 它究竟替我省掉什么？
- 我这个项目适合拿它当起点吗？
- 它和别的中后台方案有什么不同？
中后台的选型成本主要不在「能不能跑起来」，而在三年后还改不改得动。所以这一页会把代价和亮点写在一起。
30 秒结论
适合这样的项目
- 企业内部系统 / 行业业务系统 / B 端 SaaS：用户有组织归属，权限要按人按数据切
- 需要多租户：一套代码服务多个客户，且要能按版本卖不同的功能包
- 有合规与审计要求：谁在什么时候改了哪条数据、动了谁的权限，都要留痕可查
- .NET 后端 + Vue 前端的团队，希望前后端两侧都有现成规范可循
这些情况建议先别选
- 面向 C 端的门户 / 交易 / 高并发系统：它是中后台内核，设计目标不是极限吞吐
- 被锁在 .NET 6 / 8，或团队已深度绑定 EF Core：底座是 .NET 10 + SqlSugar
- 前端团队是 React 技术栈：前端是 Vue 3，迁移等于重写
- 只需要一个「有登录和菜单」的小后台：权限、租户、审计这套模型对小系统是过度设计
一、它替你省掉的那几个月
每个中后台项目开工时都要重做一遍下面这些东西。它们不产生业务价值，但每一样做不好都会在半年后变成事故：
| 你本来要写 | 它已经内置 |
|---|---|
| 登录、令牌刷新、多端会话、找回密码 | JWT 双令牌、账号密码 / 邮箱短信验证码 / OAuth2 / 2FA、会话管理 |
| 角色菜单权限，然后被业务追问「他只能看自己部门的」 | RBAC + ABAC + 数据范围 + 字段级脱敏，四个正交维度 |
| 组织架构，然后发现部门树的上下级查询很慢 | 部门闭包表 + 岗位 + 用户多部门归属 |
多租户，然后在每个查询里手动加 where tenant_id = | 字段级隔离内建于数据层，写路径有越权写守卫 |
| 操作日志，然后发现密码和令牌被明文记进了库 | 七类审计日志，落库前自动脱敏 |
| 增删改查页面，一张表写一遍 | 代码生成：实体 → DTO → API → 前端页一键产出 |
| 站内信、邮件、短信、群机器人各写一套 | 消息中心 四渠道扇出 + 模板渲染 + SignalR 实时推送 |
内置 88 张表的数据模型与 50 多个后台页面，是这些能力落地后的实际体量。
二、五个真正拉开差距的地方
「有这个功能」和「这个功能经得起用」是两件事。下面五点是它与常见后台模板的实质差异。
1. 权限不止「角色—菜单」两层
大多数后台模板的权限模型到「角色绑菜单、菜单绑按钮」为止。业务提出「区域经理只能看本区域、且只能在工作时间审批、且金额超过 50 万要转审批」时，就得改代码。
曦寒把权限拆成四个正交维度，再加两套治理机制：
| 维度 | 回答的问题 |
|---|---|
权限码 module:resource:action | 你能不能做这个操作 |
| 数据范围（本人 / 部门 / 租户） | 这个操作能作用到哪些数据 |
| ABAC 属性条件 | 在什么时间、什么 IP、什么资源状态下才成立 |
| 字段级脱敏 | 同一条数据里，哪些列你看得见明文 |
- 约束规则引擎：静态 / 动态职责分离、互斥、基数、先决条件、时间、位置等八类规则，违规可拒绝 / 警告 / 仅记录 / 转审批
- 权限委托：委托人 → 被委托人 → 权限范围 → 生效与到期时间窗，可随时撤销，全程留痕
2. 多租户是内建维度，不是补丁
多租户如果做成「在业务代码里记得加过滤条件」，那么漏一处就是数据泄露。这里它落在数据层：租户过滤由框架统一施加，全局数据用 TenantId=0 约定，写路径另有守卫防止租户态误改全局行。
配套的还有商业化需要的那部分：租户版本（Edition）以权限白名单在运行时门控功能，开通时一站式建管理员与授权，降级自动回收越权授权。超级管理员可在平台态切入任意租户代为运维。
见 多租户与版本。
3. 菜单、路由、权限码只有一份真源
后台系统最常见的腐化点，是菜单在数据库里、路由在前端代码里、权限码在第三个地方，三份逐渐对不上。
这里后端的 PageRegistry 统一登记页面码、路由路径、前端组件路径、权限码与国际化键，菜单种子据此同步；前端按后端下发的结果生成路由。新增一个页面只在一处登记，前端不再维护第二份清单。
见 菜单与路由。
4. 列表页由配置生成，且三重感知
中后台八成的页面是「搜索 + 表格 + 导出」。这里它们由 Schema 配置生成，内置列设置、密度切换、高级搜索（时间区间、枚举多选）、个人视图保存、树形模式与列宽拖拽。
关键在于它对三件事有感知：权限（页面、字段、操作三级按权限码过滤，字段级脱敏）、租户、个人偏好（列设置与搜索条件同步到后端，换台电脑还在）。
见 Schema 驱动页面。
5. 底座可以单独带走
它的后端建立在 XiHan.Framework 之上，而框架是 66 个可独立引用的 NuGet 包，本身就是公开发布的产品。
这意味着两个方向都通：你可以拿整套 BasicApp 起步，也可以只借走框架的某几个模块用在自己的项目里。BasicApp 使用的全部是框架公开的接口，没有内部特权 API——所以「先用模板上线，之后逐步换成自己的实现」这条路是通的，不需要换底座。
三、中后台方案的四条路线
同类方案不在一个平面上，而是四条路线。下面只描述路线特征，不做优劣评判——很多时候「不选曦寒」才是对的。
| 路线 | 代表 | 你得到什么 | 你付出什么 | 什么时候选它 |
|---|---|---|---|---|
| A. 从零自建 | ASP.NET Core + Vue + 自选组件 | 完全贴合业务，没有多余抽象 | 身份、权限、租户、审计要自己写并维护多年 | 系统形态特殊，且团队有稳定架构能力 |
| B. 商业中后台 / 低代码平台 | 各类商业 aPaaS 与低代码平台 | 有 SLA、有实施支持、非开发者也能配置 | 授权费用、平台绑定，深度定制受平台能力边界限制 | 需求以配置为主，且预算与合规要求指向商业产品 |
| C. 开源后台管理模板 | ZR.Admin.NET、YuebonCore 等 | 开箱就是一套完整后台，社区素材多 | 底座常与模板一体，长大后拆解成本高 | 需求接近标准后台，追求最快上线 |
| D. 框架 + 中后台内核 | Admin.NET（基于 Furion）、ABP 官方启动模板、曦寒基础应用 | 既有可投产的成品，又有可独立演进的底座 | 需要理解底座的模块化与分层概念，学习曲线更陡 | 系统会长期长大，且不希望被模板绑死 |
曦寒站在 D。 与路线 C 最实质的区别是：模板部分可以逐块替换，底座不用换。与路线 B 的区别是：全部代码在你手上，MIT 许可，没有功能墙，代价是没有商业支持。
四、用最小成本验证
别信任何一页文档的自述，点一遍最快：
| 花多久 | 做什么 | 你会验证到什么 |
|---|---|---|
| 10 分钟 | 打开 在线用例，用 superadmin / SuperAdmin@123 登录 | 交互质感与能力广度是否够用 |
| 半天 | 跟着 快速开始 在本地跑起前后端 | 上手成本，以及你的环境是否顺畅 |
| 一天 | 读 目录结构与代码地图 → 请求生命周期 → 二次开发 | 「加一个业务功能要动几个文件」这个真实成本 |
演示环境
在线用例是公开演示环境，数据会被定期重置，请勿录入任何真实数据。