4.4 底层技术栈：积木的材料学

4.4 底层技术栈：积木的材料学

本节摘要：认识平台用什么材料搭成：前端一层、后端一层、数据一层，外加把三者串起来的插件加载机制。本节不教你写每一层的代码，而是给你一张「谁住在哪一层」的地图——排障时知道日志去哪翻、插件代码住在哪、性能瓶颈通常在哪层，4.3 写的插件也就有了坐标系。

车完零件，最后看一眼材料库。这一节是第 4 章的收束，也是通往第 5 章的桥——运维排障的一半功夫，在于知道问题出在哪层材料上。

一、三层材料各管什么

前端层是单页应用，区块、字段组件、配置面板这些你在界面上看到的一切都住在这一层；它的职责是把「配置数据」翻译成可交互的界面，自己不做业务裁决。后端层是 Node 服务，负责数据访问、权限裁决、工作流执行与插件的服务端逻辑——所有真正的「规矩」都在这层执行，前端显示的可用性只是表象。数据层是关系数据库，平台默认配 PostgreSQL，也支持 MySQL 等常见库；数据表引擎把「表、字段、关系」这些概念映射到库里的物理结构。

为什么是这套组合？前端选单页应用体系，为的是配置面板与页面渲染的即时互操作——你拖一颗螺丝，界面立刻变样，没有页面刷新。后端选 Node，前后端同语言，插件开发一份技能栈通吃两侧，这是对二次开发者最实际的红利。数据层选成熟关系库而不上新兴存储，因为低代码平台的命脉是事务与约束——业务数据要的是可靠，不是新奇。

图 4-2 技术栈分层图：每层住着谁

二、插件代码住在哪、怎么被加载

4.3 写的插件在工程里住在插件包目录，构建产物随应用发布。运行时的加载过程值得理解一遍：应用启动时，内核读取插件清单，按依赖顺序逐个加载服务端入口，注册资源、监听钩子；客户端入口则由前端应用按启用清单动态加载。所以「改了插件代码没生效」的第一个检查项是「构建了吗、重启了吗」——服务端改动要重启进程，客户端改动要重新构建，两件事经常被混成一件事。

配置与元数据也在数据层：你拖的每个页面、每颗区块螺丝，最终都是配置表里的一行记录。这一点解释了两个日常现象：其一，环境之间迁移界面配置，本质是导出导入这批配置记录，第 5 章的多环境工序靠它成立；其二，配置数据的备份与业务数据同等重要——丢了配置记录，页面布局全打回原形。

三、从材料学看性能与排障

材料分层给了性能问题一个粗定位框架。前端卡：区块过多、单页数据量过大，翻 2.3 的装配纪律。接口慢：查后端日志的慢请求记录，看是权限条件复杂还是缺索引——行级权限的范围条件最终会翻译成查询过滤条件，条件字段上没有索引就是全表扫。数据层慢：外部数据源大表、跨源关联，翻 3.4 的告诫。这些判断在 5.3 会展开成完整的排错工序，本节记住「先分层、再下钻」就够。

排障的另一半是日志。服务端日志记录请求与错误，工作流执行记录存库（3.1 用过），前端异常进浏览器控制台。三处日志与三层材料一一对应——出了问题先问「哪层的日志在报警」，比打开界面乱点有效得多。

⚠️ 常见坑：绕过平台直接改库。某团队为图省事直接在库里改配置表，平台缓存与元数据校验不知情，界面开始出现灵异现象。库里的一切都可以看、可以备份，但不该手改——配置的修改永远走界面或接口。

💡 关键直觉：技术栈选型的思路是「成熟压倒新颖」。低代码平台的每一层都要承载不可预期的业务组合，久经考验的材料比炫技的新材料更适合做地基。

深入一格：一次请求的旅程

把一次「保存客户资料」的完整旅程走一遍，三层材料如何接力就活了：

一次保存请求的旅程（前端到数据层再返回）：
  1. 前端表单提交 → 组装请求体，附带认证令牌
  2. 请求管线接收 → 令牌校验，确认「你是谁」
  3. 权限裁决 → 三层锁逐层过：角色有无该操作、
     行级范围条件拼进查询、字段白名单过滤提交内容
  4. 数据层执行 → 写库，约束与必填在此兜底
  5. 钩子与流程 → 数据事件触发，工作流接棒（3.1 的扳机）
  6. 响应返回 → 前端刷新列表，界面看到新值
​

旅程图是排障的地图：保存慢，沿旅程逐站掐时间，慢在哪一站一目了然；保存报错，看停在哪一站——第二站是认证问题、第三站是权限问题、第四站是数据问题。排障从「到处点点」变成「沿图找站」，这张图就值回了学习成本。

配套再给一张插件代码的住址速查，与 4.3 的工程结构对上：

代码住址速查：
  你的插件     → 工程的插件包目录（独立仓库管理）
  官方插件     → 平台镜像或工程依赖内，只读不改
  业务配置     → 数据库配置表，界面是它的编辑器
  附件文件     → 存储目录，随备份三件套走
  修改纪律     → 前两者只读，后两者各管各的备份
​

环境变量清单：部署的底层旋钮

容器化部署的多数行为由环境变量这排旋钮控制，把常用的列成清单，装机、迁移、排障都用得上：

常用环境变量速查：
  APP_KEY          应用密钥，装后不可改，参与敏感数据加密
  DB_*             数据库六件套：类型、地址、端口、库名、账号、口令
  LOCAL_STORAGE_BASE_URL  附件访问基础地址，换域名时要改
  APP_PORT         服务监听端口，容器映射的里侧
  时区与语言类变量  影响日志时间与默认界面语言
  纪律：变量清单纳入装机记录，改动走编排文件不走容器内部
​

这排旋钮与 5.1 的装机记录是配套关系：环境变量的任何变更都是变更，都要留痕。排障时「环境变量的当前值」往往是第一现场——尤其是换过域名、迁过机的实例，附件打不开这类灵异现象，十有八九是某个地址类变量还留着旧值。

时区与字符集：跨国团队的隐藏考题

技术栈层的两个隐藏旋钮值得单独交代。时区：应用容器与数据库容器的时区要显式设成一致，否则日期字段会出现「保存时是当天、列表里变前天」的灵异现象，跨国协作的团队还要约定统一以哪一时区为准。字符集：数据库建库时确认 UTF-8，生僻字与表情符号才不会在某个接口上变成问号——这类问题事后修的成本极高，装机时五分钟就能锁死。

装机时的两条确认（写进装机记录）：
  □ 容器与数据库时区一致，与团队约定基准时区一致
  □ 数据库字符集为 UTF-8，排序规则与平台建议一致
​

装配要点回顾

• 三层分工：前端翻译配置成界面，后端执行全部规矩，数据层承载业务表与配置记录；
• 同语言红利：前后端都在 Node 生态，插件开发一份技能通吃两侧；
• 加载两步走：服务端改动重启进程、客户端改动重新构建，「没生效」先查这两步；
• 配置即数据：界面装配产物是配置表记录，迁移与备份都围绕它成立；
• 定位口诀：界面怪前端、数据怪后端、账目怪数据层、文件怪存储；
• 下一站：第 5 章走出车间，把这台机器稳稳地放到生产现场。