颜色应由前端按语义标识推导，后端只存 node_type 等语义字段，不存具体颜色值；前端用 TypeScript 类型约束 + CSS 变量 + 映射表统一管理，避免散落多处。
模型节点颜色该写在哪儿？别塞进数据库字段
颜色不是业务属性，硬塞进 node_color 这类字段里，后期改主题、加暗色模式、做 a/b 测试全得改数据甚至跑迁移。它属于表现层契约，应该由前端或可视化层按规则推导。
- 后端模型只存语义标识，比如
node_type: "error"、status: "pending"，不存"#ff4444" - 前端用映射表统一管理：{ error: "#d32f2f", pending: "#1976d2", success: "#388e3c" }
- 图谱类组件（如 Cytoscape、AntV G6）通常支持通过
style或stylesheet按data.type动态匹配样式，这才是正路
自定义颜色时，CSS 变量比硬编码更可控
直接在组件里写 color: "#5e35b1" 看似快，但换肤、多租户配色、灰度测试时，你得全局搜替换，还容易漏。
- 把主题色定义在
:root里：:root { --node-error: #d32f2f; --node-warning: #f57c00; } - 节点样式用变量：
.node.error { background-color: var(--node-error); } - 需要运行时切换？改
document.documentElement.style.setProperty('--node-error', newColor)即可，不碰逻辑
后端 API 返回 color 字段？小心缓存和一致性陷阱
有些团队让后端拼好 color 字段返回，省得前端算——这在单页应用里埋了雷。
- CDN 或网关缓存了带颜色的响应，但主题更新后前端代码已变，颜色却还是旧的
- 同一节点在不同接口里可能返回不同颜色（比如 /nodes 和 /graph/export），因为后端没共用映射逻辑
- 如果 API 要兼容老客户端，还得维护多套颜色策略，越往后越难撕
- 真要透出颜色，只应在明确的「配置接口」里返回，比如
GET /ui/theme，且带 ETag
用 TypeScript 做类型守门，防住非法颜色值传入渲染层
即使用了 CSS 变量，前端仍可能在运行时拼错 key，比如把 "warn" 传成 "warning"，结果节点变成默认色，问题难定位。
- 定义合法节点类型为联合字面量：
type NodeType = "error" | "success" | "pending" | "info";
- 颜色映射函数加类型约束：
const getColor = (type: NodeType): string => colors[type]; // type error if 'warn' used
- 后端返回的
type字段也建议加枚举校验，避免传 "ERROR" 或 "err" 这类大小写/拼写变体
颜色映射看似简单，但一旦散落在数据库、API、CSS、JS 多处，改一次主题就得查三遍日志、清两次缓存、测四条路径。真正省事的做法，是把决策点收束到一个地方——通常是前端的 theme 配置模块，其余环节只认语义，不认颜色。
