企业官网建设流程全解析

做中后台平台的同学，对“平台定制交互”这个词应该不陌生。业务方开口永远是“这个页面我们想要A效果，那个租户想要B效果”，产品文档改了三版，最后前端还是拿if/else把组件塞得满满当当。我接手过一个多品牌商城的中台项目，定制逻辑散落在各个页面里，光是订单详情页就有十几处租户分支，每加一个品牌就要复制一套页面，线上事故有一半出在改交互时误伤其他租户。后来我把整个交互体系重构成了一套三级架构，总算把这个问题按住。

所谓三级架构，不是指后端那种传统分层，而是把“平台定制交互”从能力上切成三层：基础交互层、场景组装层、业务定制层。它的核心目的是把千奇百怪的定制需求，收敛到一套可配置、可审计、可回滚的机制里，而不是让业务方每提一个需求就改一次公共组件。这篇文章适合正在做中后台平台、SaaS租户体系、多品牌前端的同学，也适合想搭一套可复用定制交互方案的团队。我会把三层怎么设计、为什么要这么切、落地时踩过的坑都讲清楚。

1. 项目背景：当“定制交互”变成灾难现场

1.1 需求背景：业务定制带来的连锁问题

先说说我遇到的具体场景。当时平台上有四个租户，分别是三个品牌商城加一个内部运营后台，共用一套订单中心、商品中心、用户中心的页面组件。问题很快暴露出来：租户A要求订单列表用卡片视图，租户B要求表格视图带行内编辑，租户C要求详情页多展示两栏售后信息，租户D直接说“我们不想用你们的弹窗，要换成抽屉”。每个需求单独看都合理，但到了代码里就是一场灾难。

最初团队的处理方式非常朴素：在公共组件上加props，比如showCardView: true、enableRowEdit: true，组件内部塞满条件判断。半年后，公共组件几乎没法再加需求了，因为每个props背后都是一串业务分支，改动任何一个分支都可能影响其他租户。后来有人开始直接复制页面，四个租户四套页面，一个公共逻辑要改四处，测试成本翻了好几倍。团队开复盘会时达成的共识是：问题不在于“定制交互”本身，而在于我们没有给定制行为划定边界。

1.2 目标与边界：给“定制”建立秩序

痛定思痛之后，我们给这套方案定了几个硬性目标。第一个目标是“默认一致，按需定制”：所有租户默认使用平台统一的交互，只有明确配置了定制项才会覆盖，这样能保证大部分场景的一致性。第二个目标是“定制必须有痕迹”：每一项定制都能追溯到具体配置、生效范围、操作人，不能像以前的if/else那样散落在代码里找不到源头。第三个目标是“定制之间互不干扰”：A租户的定制只能作用在A租户的渲染链路上，不能通过事件、样式等间接影响B租户。

同时我们也明确了边界：三级架构解决的是交互层的问题，不包含数据服务端的权限设计，也不包含视觉设计系统的全部内容。它只需要管一件事，当同一个页面被不同身份、不同场景使用时，如何优雅地展示不同的交互形态。有了这个边界，后面设计三层时就不会什么都往架构里塞。

2. 三级架构的核心设计思路

2.1 第一级：基础交互层（原子能力）

基础交互层是整个体系的地基，我习惯叫它“交互原子库”。它不关心业务，只提供最基础的交互单元，比如按钮、输入框、表格、弹窗、抽屉、分页器、校验规则、空状态、异常态。每一类原子能力都要遵循统一的设计规范，比如圆角、间距、主色、动效时长，并且通过CSS变量暴露出来，保证后续定制能改色、改间距而不动组件代码。

这层的关键要求是“纯净”。任何业务字段、租户判断都不允许出现在基础组件里，组件只接收结构化的props，输出标准化的交互行为。为了做到这点，我们把之前公共组件里积累的条件分支全部拆了出去，组件内部彻底回归“无业务逻辑”的状态。这个过程很痛苦，但换来的是基础组件可以被任何场景、任何租户稳定复用，也能在视觉规范升级时只改一层，不用追杀几十个页面。

2.2 第二级：场景组装层（编排能力）

第二层解决“同一批原子能力如何组装成页面”的问题。我们把它设计成可配置的场景组装层：页面不再由硬编码的代码拼出来，而是由一份配置清单定义。配置清单里写明这个页面使用哪些组件、组件顺序、默认props、栅格布局、状态映射，比如订单列表页就是“筛选区+表格区+分页区+批量操作区”，每块引用哪个基础组件一目了然。

这一层也是首次引入“按条件命中”的地方。配置可以附带匹配规则，比如租户ID、用户角色、是否移动端、请求参数等。命中规则后，场景组装层会生成一套该场景专属的交互预案。我举个具体例子，运营后台的订单列表默认是表格视图，匹配规则命中“租户B”时，会额外注入行内编辑能力并切换为紧凑密度。这些变化都记录在配置里，而不是写死在组件里，改起来只需要调整配置。

2.3 第三级：业务定制层（扩展能力）

业务定制层是给那些实在没办法用配置表达的需求留的口子。比如某个租户要求点击订单号时弹出详情抽屉，同时对抽屉内部做一次数据聚合展示，这种个性化逻辑很难靠配置项穷举。所以第三层提供三类扩展机制：插槽覆盖、逻辑钩子、事件订阅。

• 插槽覆盖：允许业务方替换页面中的某个区块，比如把两列售后信息改成三列。
• 逻辑钩子：在关键流程点（如提单前、回滚后）注入自定义逻辑，比如追加一次埋点调用。
• 事件订阅：业务方监听平台事件，做自己的后续处理，比如监听“订单刷新成功”后同步刷新一个侧边栏。

这三类扩展都必须注册在案，不允许业务方直接改公共组件文件。注册接口内部会做作用域隔离，确保扩展只挂载到当前租户的渲染链路。

2.4 为什么是三级，而不是两级或四级

很多团队会问，为什么一定要切三层，把组件和定制合并成两层不行吗？我最初也试过“基础组件+定制补丁”的两层方案，后来发现两层有个致命问题：基础组件一旦被定制逻辑直接打补丁，组件的纯净性就被破坏了，很快又长回原来那棵条件分支大树。切出中间的场景组装层，是为了让“默认怎么组装”和“个别怎么改”有一个天然的缓冲地带，定制不再直接修改基础组件，而是修改上层的组装产物。

反过来，也不建议再加一层。我见过有人把架构切成“设计令牌-基础组件-场景模板-业务页面-定制补丁”五层，听起来很完善，实际用起来每个改动要穿透四五个配置文件，心智负担极高，团队新人上手时间翻倍。三层的粒度对绝大多数中后台场景都够用：底层管能力，中层管组装，上层管覆盖。这也是三级架构最实用的形态。

3. 落地实操：从0到1搭建三级交互架构

3.1 目录结构与分层约定

先讲落地时的目录结构。我们按三层把代码物理隔离，避免业务方不自觉地把定制逻辑写到公共组件里。一个典型的项目目录大概是这样：

src/ deep-content/ // 第一级：交互原子库 button/ table/ dialog/ drawer/ form/ index.js presentation/ // 第二级：场景组装层 schemas/ order-list.js order-detail.js resolvers/ schema-resolver.js index.js experience/ // 第三级：业务定制层 extensions/ tenant-a/ tenant-b/ hooks/ index.js platform/ // 运行框架，配置中心、合并引擎 config-center.js merge-engine.js

这里目录名我刻意用了“deep-content / presentation / experience”这种语义化的命名，而不是简单叫“base / middle / top”，目的是让每个开发者一进项目就明确知道：自己写的代码属于哪一层，应该遵循什么约束。团队约定三条红线：第一，第一级组件不允许出现任何业务标识；第二，第二级只做组装和命中，不写租户特判；第三，所有定制逻辑必须通过第三级注册入口进入系统。

3.2 第一级的实现要点

基础交互层落地时，最核心的一件事是制定“协议优先”的组件规范。什么意思？就是每个组件对外暴露的交互能力，先用协议声明出来，再实现具体代码。比如表格组件声明自己支持viewMode（卡片或表格）、density（紧凑或宽松）、rowEdit（行内编辑）、expandable（展开行）等能力，每个能力都有默认值和枚举范围。

我们用一个能力注册表来管理这些声明：

// table 组件的能力声明 export const tableAbilities = { viewMode: { default: 'table', options: ['table', 'card'] }, density: { default: 'comfortable', options: ['compact', 'comfortable', 'loose'] }, rowEdit: { default: false, type: 'boolean' }, expandable: { default: false, type: 'boolean' } };

有了这份声明，场景组装层在生成配置时就能校验值是否合法，不合法的配置直接报错，而不是等到运行时悄悄失效。这层还要求所有组件用CSS变量定义视觉参数，比如弹窗宽度用--dialog-width、圆角用--radius-md，这样业务定制层做视觉微调时只需要覆盖变量，不碰组件内部样式。

这一层踩过的坑是“能力清单过度设计”。最早我们想做一个无所不能的表格，什么交互都支持，结果组件props膨胀到几十个，别人根本不知道怎么用。后来改成“由场景反向定义能力”，每个能力必须至少被两个业务场景用到，否则不纳入基础组件，宁可让定制层去扩展，也不让原子库背债。

3.3 第二级的配置化落地

场景组装层的核心是定义页面Schema，我建议用“区块树”来描述页面，不要用简单的平铺数组。区块树能表达区块之间的嵌套关系，比如“订单详情页”里有“订单信息卡”，“订单信息卡”里又有“商品明细表”，这样可以做到任意层级插拔。一个简化版的Schema如下：

const orderDetailSchema = { version: '2.1.0', scene: 'order-detail', base: { layout: 'vertical', blocks: [ { id: 'order-info', component: 'InfoCard', props: { title: '订单信息' } }, { id: 'receiver-info', component: 'InfoCard', props: { title: '收货信息' } }, { id: 'goods-table', component: 'Table', props: { columns: [], loading: true } }, { id: 'action-bar', component: 'ActionBar', props: { actions: [] } } ] }, presets: [ { name: 'tenant-b-card-view', when: { tenantId: 'B' }, patch: { 'goods-table': { viewMode: 'card', rowEdit: true } } }, { name: 'mobile-minify', when: { isMobile: true }, patch: { 'order-info': { collapsible: true }, 'action-bar': { sticky: true } } } ] };

运行时的过程是这样的：先合并基础schema，遍历presets，逐个判断when条件是否命中，命中的就把patch里的内容合并到对应区块的props上。区块标识（id）是合并的锚点，所以每个区块都要有稳定且唯一的id，命名建议用“场景-模块-含义”，比如order-detail-goods-table。

实现合并时一定要用深合并，并且区分“覆盖”和“追加”。比如卡片视图这个能力，A租户命中后改成card，B租户没命中就保持默认table，这就是覆盖。而像表格操作列，可能需要在默认操作后面追加一个自定义按钮，这是追加。我们在合并引擎里写了两个方法，assign表示覆盖，concat表示追加，业务配置时按需选择，避免出现“想追加结果把原有的覆盖了”这类坑。场景组装层的详细配置可以从配置中心下发，这样调整交互就不需要重新发版本，刷新页面即生效。

3.4 第三级的扩展机制落地

业务定制层落地时，我坚持把“注册”和“执行”分离。所有业务扩展首先要在定制注册中心登记，注册时声明作用范围、扩展类型、优先级、降级策略。系统运行时只认注册中心的合法扩展，没有登记的补丁一律不生效。这样做的好处是配置可巡查，运营同学可以从后台看到每个租户当前挂了哪些扩展，出问题能精准定位。

下面是一个逻辑钩子的注册示例：

custom.register({ scope: 'tenant-b', type: 'hook', phase: 'beforeSubmit', handler: async (ctx, next) => { ctx.payload.salesNote = await getSalesNote(ctx.orderId); await next(); }, priority: 10, fallback: 'skip' });

这里phase是钩子的执行时机，priority控制同阶段多个钩子的执行顺序，fallback: 'skip'表示如果这个钩子抛错，不影响主流程继续。这个设计是我强烈建议保留的，因为第三级扩展是业务方写的代码，质量参差不齐，如果没有fallback机制，一个定制钩子的异常会导致核心页面挂掉，这在线上是不可接受的。

事件订阅方面，我们通过一个事件总线实现，所有平台事件先广播到总线，订阅方按事件类型筛选。这里最需要注意的是事件名规范化，我们统一采用“domain:action:result”三段式，比如order:submit:success，避免出现同义事件名互相收不到的情况。同时，业务定制的监听器必须实现幂等，比如重复监听同一个“刷新成功”事件时，不能重复请求接口，否则定制越加系统越卡。

3.5 配置热更新与灰度发布

三级架构带来的一个重要好处是“交互配置可以热更新”。我们将每份场景Schema和定制补丁都存储在配置中心，发布流程走“预发—灰度—全量”三个阶段。灰度阶段可以指定某个租户内一定比例的用户先看到新交互，比如先把租户B的20%流量切到新版卡片布局，观察监控指标没问题再逐步放开。

这一块必须有配置版本管理，每次改动生成新版本号，线上配置与历史版本对比一目了然。我加了一个简单约定，配置版本与代码发版解耦：代码发版处理能力新增，配置发布处理交互调整。前端本地只需要缓存版本号，配置中心下发新版时自动拉取，并在渲染前做一个旧版回滚开关，一旦新版Schema解析失败，自动回退到上一版本渲染。这套机制上线后，很多以前要熬夜发版解决的交互问题，现在运营自己点点后台就改完了。

4. 常见问题与排查技巧实录

4.1 样式覆盖优先级混乱

三级架构落地初期，最头疼的是样式问题。业务定制层通过CSS变量改视觉，但经常出现“变量改了没生效”或者“影响了别的租户”的异常。排查下来，大部分原因是全局样式优先级和组件样式隔离没做好。我们的解法分三步：第一，所有基础组件的视觉参数统一走CSS变量，禁止在组件里写死颜色值；第二，定制层的样式全部作用到带租户前缀的容器节点上，比如.tenant-b .order-detail { --primary-color: red; }，避免污染其他租户；第三，样式文件按层构建，基础层的样式文件最后加载，定制层的样式文件最先加载，保证定制优先级天然更高。

4.2 定制逻辑与公共逻辑的冲突

另一个高频坑是事件冲突。我们有一次上线后发现订单列表的刷新按钮被连续触发两次，表现是列表闪两下、接口请求翻倍。追查后发现是租户B的定制逻辑监听了一个旧版事件名，平台又新增了一个同义事件名，两边同时触发刷新。后来我们把事件名统一管理起来，事件总线里注册的事件必须在配置平台登记，重复语义、同义事件在发布时直接拦截。另外，所有定制逻辑都要做到可重入，也就是重复执行不产生副作用，这个约束写进了代码评审清单，只要定制代码里出现“直接修改全局变量”或者“重复请求接口”，评审就不通过。

4.3 配置漂移与版本失控

配置多了以后，容易出现“线上交互行为与预期不一致”的问题，也就是配置漂移。表现是某租户明明配置了卡片视图，线上却还是表格。排查中发现，有人在另一个配置入口又发布了一版Schema，后发布的把先发布的覆盖了，但覆盖粒度是整个场景，把之前精心配置的补丁一起冲掉了。这个问题可以通过引入“注册表+审计日志”解决，每个场景只允许有一个生效的Schema版本，所有变更写入审计日志，后台可以按时间线回放这个页面从今天早上到现在经历了哪些配置变更。同时，不要给太多人配置中心权限，生产环境的配置发布要跟代码发布一样走审批流。

4.4 性能劣化：定制补丁拖慢首屏

定制功能做得越多，性能越容易失控。我们有次性能巡检发现订单详情页首屏耗时从800ms涨到了1400ms，逐一排查后定位到是定制层挂了7个钩子，其中三个都做了异步数据请求，串行执行后整整多出近600ms耗时。整改方案是给定制扩展做执行策略的分级，纯展示的补丁直接同步合并到Schema里，数据型钩子优先并行执行，必须串行的尽量前置缓存。我们还加了一个定制预算面板，后台能看到每个租户的扩展数量、钩子执行耗时、失败次数，超过预算的租户会被警告。

5. 这套架构带来的实际收益

从结果上看，一个表格就可以说清楚重构前后的对比：

收益不只是效率上的。更关键的是，团队的代码心态发生了改变，以前大家防守公共组件像防守阵地，任何改动都战战兢兢，现在有了清晰的层边界，该加能力的去第一级加能力，该做编排的去第二级排，该做定制的去第三级注册，各自有各自的战场。产品经理提需求时也会主动问一句“这个是平台默认能力还是租户定制需求”，需求从一开始就被归类，而不是混在一起。

从业务价值角度看，这套架构还直接保护了定制经验。以前给某个租户做的交互优化，换个页面经理就找不到了，现在所有经验沉淀为配置和已注册的扩展，可以被下一个类似租户复用。对我们做中后台平台的同学来说，定制不是敌人，混乱才是。

6. 最后的实操体会与建议

踩过这么多坑，我最想分享的一条经验是：不要把三级架构当成纯技术方案，它更是一种对人性的约束。团队里总有同事觉得“这次需求很简单，我直接改一下公共组件就行”，如果没有层边界和评审红线，架构再漂亮也会在一周内退回原形。所以落地时一定要配合代码评审和工具约束，比如CI流水线扫描第一级组件目录里是否出现业务字符串，出现了就打断合并，让规则说话。

如果你准备在现有项目里改造，我建议不要一次性推倒重来，先选一个高频页面做试点，把它的交互拆成三级，跑通配置发布和回滚链路，再逐步铺开。改造过程中要给老逻辑留一段过渡期，用开关切换新旧渲染路径，确认数据一致后再删旧代码。最后再分享一个小技巧：三级架构的每个层级都要有一个“默认路径”，也就是不配置任何定制时系统也能跑得很好，架构复杂不等于使用复杂，绝大多数租户应该永远走在默认路径上。这一点保持住了，这套三级架构才不会变成负担，而是真正帮你把混乱变成秩序。