如意 Django CRM Admin UI 设计复盘：固定框架、任务导航与石绿松风

OK，OK，大家好，欢迎大家来到大鹏 AI 教育，我是张大鹏。

一个模型越来越多的 Django Admin，最先失控的通常不是功能，而是页面秩序。

顶部跟着页面离开视口，左侧菜单长到需要单独滚动，内容区又没有真正使用剩余宽度。

当颜色散落在模板和组件中以后，选中态、按钮、文字和滚动条还会逐渐长成几套风格。

如意 Django CRM 的改造目标很明确：让后台成为一个位置稳定、任务清楚、适合长时间工作的内部平台控制台。

现在落地的结果是固定顶部、固定侧栏、内容区独立滚动，以及统一的“石绿松风”主题系统。

一、先让后台拥有稳定的工作位置

后台不是一张固定比例的海报。

它必须铺满浏览器可用视口，并在表格、表单和审计记录不断增长时保持全局操作的位置稳定。

1.1 顶部、侧栏和内容区怎样分工

先看完整工作台的空间关系。

画面中哪些区域始终固定，哪一块真正承担内容滚动？

三个区域的职责可以从边界和尺寸上直接辨认。

• 🧢顶部区域：高度固定为64px，承载品牌、语言、主题状态和账号入口。
• 🗂️左侧区域：桌面宽度为232px，只负责平台概览、任务域和当前模型入口。
• 🖥️内容区域：使用minmax(0, 1fr)获取扣除侧栏后的全部剩余宽度。
• 🧵滚动区域：页面外层禁止滚动，只有内容容器在数据超高时纵向滚动。

我的判断是，固定框架解决的不是视觉上的整齐，而是管理员的操作位置不能随着内容漂移。

这套空间关系最终形成四条实现约束。

• 📐视口自适应：应用宽高跟随浏览器可用空间，不对整个页面做等比缩放。
• 🧮剩余空间：内容宽度自然等于屏幕宽度减去侧栏宽度。
• 🪟局部滚动：表格或表单变长时，顶部与任务入口仍保持可见。
• 🧷收缩保护：网格轨道和滚动容器设置min-width: 0与min-height: 0。

最关键的 CSS 关系可以压缩为下面几行。

html, body{width:100%;height:100%;overflow:hidden;}.app{height:100%;display:grid;grid-template-rows:64pxminmax(0,1fr);}.workspace{min-height:0;display:grid;grid-template-columns:232pxminmax(0,1fr);overflow:hidden;}.content{min-width:0;min-height:0;overflow:auto;}

minmax()与overflow的行为可以分别参考 MDN。

https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Values/minmax

https://developer.mozilla.org/en-US/docs/Web/CSS/overflow

1.2 窄屏怎样受控降级

固定侧栏不等于所有屏幕都使用同一个宽度。

后台按照三个清楚的宽度档位逐级收缩。

• 📏桌面视口：宽度不低于1024px时，侧栏保持232px。
• 🧳平板视口：768px到1023px之间，侧栏收窄到208px。
• 📱窄屏视口：低于768px时，侧栏使用184px，内容区继续获取剩余宽度。
• 🛟应急滚动：只有侧栏内容确实超过视口高度时，才允许侧栏自身滚动。

窄屏不是把桌面后台强行压成手机应用。

它只保证关键入口仍然可达，不遮挡内容，也不重新引入全局滚动。

二、让侧栏围绕任务而不是模型目录

Django Admin 默认按应用和模型展示导航。

模型较少时很直接，CRM 模块增加以后，同一层级会同时出现客户、线索、商机、发票、任务、权限与系统配置。

2.1 为什么任务域比完整模型树更稳定

新的侧栏先回答“管理员现在要处理哪类工作”，再回答“具体进入哪个模型”。

• 🧭客户增长：集中客户、联系人、线索与商机等增长对象。
• 🧩销售履约：集中订单、报价与发票等交付对象。
• 🛠️服务协作：集中任务、工单与协作记录。
• ⚙️系统治理：集中用户、权限、审计和平台配置。

进入某个业务域以后，侧栏最多展示五个模型。

如果当前页面对应第六个或更靠后的模型，它会替换普通条目进入可见区域。

这样既守住了侧栏高度，也不会让管理员失去当前位置。

2.2 精简导航不能绕过 Django 权限

任务导航只是重新组织 Django 已经授权的入口，不是另一套权限系统。

• 🔐权限来源：导航数据继续来自 Django Admin 过滤后的available_apps。
• 🪪人员边界：只有 Django staff 才能进入后台，普通登录用户仍然被拒绝。
• 🏢数据范围：后台面向开发、运维和平台管理员，默认展示全平台数据。
• 🧾原生能力：模型 URL、CSRF、表单、删除确认和审计历史保持不变。

这条边界很重要。

界面看起来更像工作台，并不意味着它变成了租户员工使用的 CRM 业务端。

三、用一套主题令牌管理中国色

布局决定操作效率，主题决定长时间使用时的阅读感受。

为了判断颜色而不是重新判断结构，中国红、中国绿和中国蓝使用相同的信息层级与组件位置。

3.1 石绿松风为什么适合日常后台

石绿松风使用#123746作为顶部深色，#2F7D6D作为主色。

后者延续了如意 CRM 已有的品牌主色。

• 🌱品牌连续：后台、登录页和公共品牌配置保持同一绿色家族。
• 👁️阅读稳定：深青文字、暖白卡片与低饱和浅绿形成清楚层级。
• 🎯状态明确：当前任务、按钮、链接、焦点和滚动条共享语义主色。
• 🧑‍💻工作属性：画面沉静克制，适合平台管理员连续处理数据。

选择默认主题不能只看主色是否好看。

更重要的是文字、边框、背景和状态反馈能否构成稳定系统。

3.2 宫墙朱砂怎样保持克制

中国红方向使用深红顶部、朱砂主色和暖纸色背景。

红色进入大面积后台以后，哪些位置保持克制才能避免压迫感？

画面没有把所有按钮和卡片都染红，而是建立了清楚的色彩层级。

• 🏯顶部背景：#5E211D承担最深的品牌锚点。
• 🧧主操作色：#A33A32只进入选中项、按钮和关键焦点。
• 📜页面底色：#F7F2EA用暖白降低红色连续出现的刺激。
• ✨金色点缀：#B58A42只用于少量文化提示，不承担正文信息。

我更愿意把这种红色用于品牌展示或重大配置入口，而不是全天候默认主题。

它需要守住三条使用边界。

• 🧯危险语义：品牌红不能替代错误和删除操作的危险色。
• 🧘视觉节奏：大面积区域继续保持暖白，让朱砂只负责层级反馈。
• 🎚️主题定位：红色表达权威感，但不改变导航与数据操作方式。

3.3 石青云海怎样强化技术感

中国蓝方向使用深海蓝顶部、石青主色和带冷感的浅灰页面。

蓝色主要改变了品牌情绪，还是改变了信息层级？

从完整页面可以看到，布局、密度和组件关系都没有移动。

• 🌊顶部背景：#183E5A让全局工具区更接近技术控制台。
• 🛰️主操作色：#316A8B用于选中态、链接、图标与滚动条。
• 🧊浅色层级：#DDEAF1承担高亮底色，避免高饱和 SaaS 蓝。
• 🪨中性色彩：#F3F5F3与#162938保持正文阅读对比。

我的看法是，石青云海适合偏开发、运维和数据管理的使用习惯。

它同时证明了主题系统的一个基本原则。

• 🔗结构不变：更换主题后，导航层级和内容宽度不能发生变化。
• 🚦语义不变：成功、警告、危险和信息状态继续使用共享状态色。
• 🧰体验不变：颜色可以改变平台气质，但不能改变用户已经熟悉的操作位置。

四、把设计规则映射到 Django Admin

Django 官方允许项目模板覆盖 Admin 模板，也支持只修改必要的模板接缝。

https://docs.djangoproject.com/en/6.0/howto/overriding-templates/

4.1 为什么要集中管理主题样式

项目把主题值集中到一个 Admin 样式入口，再由页面组件读取语义变量。

• 🎨颜色令牌：统一顶部、主色、页面、卡片、文字、边框和文化点缀。
• 🧱布局令牌：集中定义顶部高度、侧栏宽度和内容区空间关系。
• 🌀交互令牌：统一圆角、阴影、焦点环、悬停状态与滚动条外观。
• 🌍语言容量：简体中文、繁体中文和英语共用结构，不依赖固定文字长度。

集中令牌带来的直接收益，是修改主色时不必追着模板中的十几个十六进制颜色逐个替换。

深色模式也可以沿用同一组语义名称，只覆盖对应值。

4.2 为什么只做浅层模板扩展

这次改造没有引入第三方 Admin 主题，也没有另建一套后台前端。

项目继续继承 Django 原模板，只覆盖品牌头部、平台首页和侧栏等必要位置。

• 🧬升级兼容：尽量复用原生模板块，减少 Django 升级时的维护面积。
• 🧿行为保留：列表、筛选、表单、删除确认和历史记录继续使用原生流程。
• 🔌脚本收敛：移除侧栏折叠与快速筛选控件后，同时停用只服务这些控件的脚本行为。
• 🧪测试保护：导航权限、平台范围、三语言和主题合同都有聚焦测试约束。

视觉改造的价值来自秩序，而不是覆盖得越深越好。

当原生能力已经可靠时，浅层扩展往往比重写整套后台更可持续。

五、用真实页面证明设计成立

静态效果图只能说明视觉方向。

最终验收必须回到 Django Admin 的真实模板、真实权限和真实浏览器布局。

5.1 自动化检查证明了什么

当前实现完成了聚焦测试、代码检查和 Django 系统检查。

• ✅聚焦测试：Admin 工作台与国际化相关的21项测试全部通过。
• 🧹代码质量：修改过的 Python 文件通过 Ruff 检查。
• 🩺系统状态：python manage.py check没有发现配置问题。
• 📎迁移边界：迁移漂移检查没有生成新的模型变更。

这些检查覆盖了 staff 访问、非 staff 拒绝、平台范围、组织字段可见性、模型权限和三种语言。

它们证明的是后台行为没有因为换肤而绕开原有边界。

5.2 浏览器验收还要看哪些细节

真实浏览器分别检查了1440、1366、1024、800和375px宽度。

• 🖼️框架尺寸：顶部始终为64px，侧栏宽度按三个断点稳定切换。
• 🧲滚动归属：页面本体没有出现纵向滚动，长内容由内容区独立承接。
• ⌨️可访问性：键盘焦点使用双层轮廓，主要文字组合达到 WCAG AA。
• 🌗主题状态：浅色、深色、简体中文、繁体中文和英语均完成页面检查。
• 🪛脚本运行：浏览器控制台没有出现侧栏脚本错误。

WCAG 2.2 对普通文字最低对比度的说明见官方标准。

https://www.w3.org/TR/WCAG22/#contrast-minimum

固定框架、任务导航与石绿主题最终解决的是同一个问题：

让管理员在复杂数据中始终知道自己在哪里、能够去哪里，以及当前操作属于什么范围。

中国红和中国蓝提供了清楚的主题参照，但当前后台只落地石绿松风。

这种取舍保留了未来扩展空间，也避免为了“可切换”提前维护三套并未投入使用的样式。