企业官网建设流程全解析

做了好几年B端产品，我最大的感受是：原型图画得像草稿，开发就敢给你还一个草稿出来。所谓Axure高保真Web开发常用组件，说白了就是把导航、表格、弹窗这些天天要用的界面元素，提前做成一套规范、可复用、带交互状态的元件库。我自己是从一个个页面复制粘贴开始，后来踩坑踩多了，才慢慢攒出一套组件体系。这篇文章不聊虚的，把我在Axure里搭Web组件库的思路、命名规范、常用组件拆解、组件通信和交付开发的经验一次说清楚。

1. "高保真"三个字，难住的是产品还是开发

1.1 高保真不等于截图级还原，而是状态完整

很多团队一提高保真，第一反应就是"像素级对齐设计稿"。但放到Axure原型这个场景里，高保真的核心其实不是画得像，而是状态完整。开发拿到一套原型，最怕的不是颜色差两个色号，而是不知道按钮按下去长什么样、输入框填错怎么提示、列表没数据的时候页面空着还是给个占位。这些交互状态不画清楚，开发就只能靠猜，猜对了是运气，猜错了就是返工。

我举个例子。一个最普通的登录表单，看起来就两个输入框加一个按钮，但如果要认真做高保真，至少要覆盖这些状态：输入框默认态、聚焦态、输入内容后的状态、校验错误的红框、禁用状态、按钮正常态、鼠标悬停态、按下态、加载中状态、登录失败后的全局提示。这还没算密码可见切换、记住我勾选、忘记密码入口。你把这一套状态在Axure里完整表达出来，开发照着写逻辑基本不用动脑，测试也能直接用这套状态列表整理用例。

那这和组件化有什么关系？关系太大了。如果你每个页面都临时画一遍这些状态，一个项目三五十个页面，光画表单就能把人画吐。更麻烦的是，画完A页面后想改一下按钮的圆角，B、C、D页面里的旧按钮不会自动跟着变，你只能全站搜索手动改，改漏了就成了线上事故。组件化就是把"状态完整性"这个要求和"复用"绑在一起，一次性把状态做全，之后每个页面拖出来就能用，改一处全局生效。

1.2 组件化解决的不只是画得快，还有改得动

我在早期带项目的时候吃过几次亏。有一次原型里导航菜单从5个变成7个，我熬夜翻了几十个页面逐一手动加菜单项，第二天还被开发吐槽"导航样式不一致"。那次之后我彻底想明白一件事：Axure里画页面只是表象，真正值钱的是可维护性。而可维护性的地基，就是组件化。

组件化的本质是什么？是把你常用的Web界面元素抽象成可复用的零件，然后给这些零件定好规则。比如导航栏做成母版，所有页面拖同一个母版，以后加菜单项、改Logo、调整栏高，都只需要动母版一个地方。再比如表格做成中继器组件，数据源统一维护，排序、分页、选中这些交互都封装在组件内部，普通页面只是"喂数据"和"接事件"。这样一来，你画原型的重心就从"一笔一笔画界面"变成了"组装界面"，就像前端工程师用组件库写页面一样。

而且组件化这件事，天然和前端组件库是同构的。你在Axure里定义的按钮、表单、弹窗、分页器，如果命名和交互逻辑直接对标Element UI、Ant Design这类前端组件库，开发拿到原型后几乎可以一一映射着写代码。这也是我后来坚持在原型里给组件写"前端对应关系"的原因——原型不只是给老板看的演示稿，它其实是开发规范的一个可视化入口。

2. 搭组件库前的底层准备：命名规范、样式底座和母版思维

2.1 给每一个元件起名：没有命名规范，组件库就是天坑

在Axure里做组件库，第一个要过的坎不是画功，是命名。很多人画原型时元件名全是"矩形1""文本2""动态面板3"，开始做单页演示没什么感觉，等做组件库时就会发现问题：一个弹窗里有遮罩、标题、关闭按钮、内容区、确认按钮、取消按钮，你在交互面板里想精准选中"关闭按钮"时，满屏的"矩形7""矩形8"会让人崩溃。

我的命名规则很简单，就三部分：模块_用途_状态，全部小写加下划线。比如：

• nav_menu_item_active：导航菜单选中项
• form_input_error：表单输入框错误态
• table_row_selected：表格选中行
• dialog_btn_confirm：弹窗确认按钮
• cart_badge_count：购物车角标数字

这套命名的好处有几个。第一，Axure的交互用例和事件表里，元件名会被大量引用，名字有业务含义，后期维护的时候不用一层层点进去猜。第二，交付给开发时，前端在写class名或变量名时可以拿你的命名当参考，沟通成本直接降一截。第三，如果你用Axure的"元件库"功能做成.rplib文件，命名规范的元件在库里扫一眼就知道是干什么的，团队的其他人拖起来也顺手。

这里多提醒一句：命名最好在画组件之前就定下来，不要画完之后再批量改名。Axure虽然支持批量重命名，但改完名之后，已经写好的交互用例里的引用关系很容易断掉，尤其是那些用文本逻辑匹配的地方，断掉之后排查起来相当费时间。

2.2 样式底座：先定义颜色、字号、间距、圆角

很多人搭组件库上来就画按钮画输入框，画到一半发现每个页面的主题色都不一样，左边用了#1890FF，右边用了#0EA5E9，最后还得回头统一。我的做法是，先把"样式底座"作为一个专门的页面放在组件库里，所有组件都从这个底座上取值，不改底座的色值就不许给元件换颜色。

这个底座页长什么样？简单说就是一张样式规范表，按模块列出所有视觉token。不需要像设计系统那么复杂，但至少要包含：

• 主色、辅助色、成功色、警告色、错误色、信息灰
• 主文字色、次要文字色、禁用文字色、边框色、分割线色
• 字体族、正文尺寸、辅助文字尺寸、标题尺寸、行高
• 圆角半径：小圆角2px、中圆角4px、大圆角8px、全圆角999px
• 间距：以8px为基准网格，8/16/24/32/48

为什么强调8px网格？因为现在主流前端组件库基本都遵循8px的设计规范，你按照这个网格去定义组件高度和间距，比如按钮标准高度32px或40px，表单间距16px或24px，开发拿过去几乎不需要换算。我自己做的时候甚至会把Element UI的官方尺寸直接抄进规范页，毕竟前端已经帮我们验证过这套间距在真实界面上的可读性和可点性。

样式底座的另一个作用，是让组件库的"一致性"变得可检查。你不再需要靠眼睛去判断两个弹窗的圆角是不是一致，直接拿规范页对照就行。这个页面对设计还原度提升的帮助，比你在组件库里多画十个组件都大。

2.3 母版和动态面板：组件复用的两个核心容器

Axure里复用一个组件，主要就两个容器：母版和动态面板。很多人分不清什么场景用哪个，我的经验是：母版管"整站的静态框架"，动态面板管"局部的交互状态"。

母版适合放那些在多个页面中固定出现、几乎不随页面变化的模块。最典型的就是全局顶部导航、侧边栏、页脚、Cookie弹窗。你在母版里画一次，全站页面拖进同一个母版，以后要调整导航菜单的文案，只需要改母版本身，所有引用母版的页面自动更新。这一点在Web项目里尤其好用，因为B端系统的框架层几乎每个页面都一样，用母版能省掉大量重复工作。

动态面板则适合放同一组件在不同状态下的切换。比如轮播图的多帧切换、Tab标签的内容切换、下拉菜单的展开收起、弹窗的显示隐藏。动态面板允许你定义多个State，每个State是一套完整的界面，然后通过交互事件在这些State之间跳转。如果你做的是高保真原型，动态面板基本就是承载交互状态的核心容器。

那母版和动态面板能不能结合？当然可以。最常用的做法是：对外暴露的是一个母版，母版内部塞动态面板。比如我做的"全局弹窗"母版，里面放了一个动态面板，动态面板的State1是空态，State2是普通提示弹窗，State3是带表单的弹窗。页面引用这个母版后，通过事件可以动态切换母版内部的面板状态，外面看起来就是同一个弹窗组件撑起了多种业务场景。这套"母版+动态面板"的组合拳，也是我做高保真Web组件库的底层地基。

3. 高频Web组件的制作拆解：导航、轮播、表格、弹窗

3.1 顶部导航与Tab切换：用动态面板管理选中态

导航是Web项目的脸面，但也是最容易被原型忽略交互细节的地方。很多原型里的导航就是几行文字，点一下没反应、选中态也没有，开发拿到手只能自己脑补高亮逻辑。我的做法是做一个导航母版，把菜单项和选中态都装进去。

具体拆解一下：导航栏分两层，上面是Logo区和全局操作区，下面是菜单区。每个菜单项我建议用一个动态面板来实现，动态面板里定义两个State：State1是非选中状态，文字色为次要色；State2是选中状态，文字色为主色，下面加一条2px的指示条。然后在每个菜单项上添加交互事件：鼠标单击时，先把所有菜单项切换到State1，再把当前点击项切换到State2。这样菜单的选中态就完全可控了，而且用动态面板切换状态比写一堆"设置文字颜色"的用例要快得多，也不会出现漏改某个样式的问题。

Tab切换和导航是同一个套路，唯一的区别是Tab还经常带着内容面板联动。比如页面上有一个Tab选项卡和一个内容区域，Tab切成"方案一"时，内容动态面板切到第1帧；切成"方案二"时，内容切到第2帧。这时候我的习惯是把Tab的选中态和内容面板的当前帧放在同一个动态面板里管理：外层动态面板有3个State，每个State里同时包含"Tab选中样式+对应的内容区"，切换时整体切换。这样两个地方的联动就天然一致了，不需要写"同时改Tab样式和改内容帧"这种容易出错的用例。

3.2 轮播图：自动播放和手动切换的组件逻辑

轮播图几乎是Web产品首页逃不掉的组件，在Axure里做轮播图其实不难，但很多新手会卡在"自动播放"和"手动切换"这两个逻辑上。

我的标准做法是这样的：轮播图外层是一个动态面板，假设有3张图，就让动态面板有3个State，每个State是一整张Slide，包含图片、标题、描述和对应的跳转热区。然后在动态面板上设置"载入时"事件：等待3000毫秒，然后执行"切换到下一帧"，同时勾选"循环切换"。这里的关键是循环选项，Axure的动态面板切换状态时如果勾选了循环，最后一帧之后会自动回到第一帧，这样自动播放就转起来了。

手动切换做起来要稍微注意一点。左右箭头各是一个按钮，点击箭头时切换到上一帧或下一帧，同样勾选循环。由于自动播放也在同一个动态面板上，手动切换之后要防止自动播放逻辑继续跑，否则会出现手动点了一下，轮播图马上又被自动切走的尴尬。我的解决办法是给动态面板加一个"状态变化时"事件：只要用户点击过箭头，就重新计时。具体实现方式是在点击箭头时，先停止当前自动播放的用例，再切换帧，然后再重新发起一个新的3秒循环。这一点虽然啰嗦，但对高保真演示体验非常重要。

至于轮播图下面的小圆点指示器，我一般也是用动态面板做。3个圆点组成一个动态面板，每个State对应当前激活的圆点位置。轮播图切换帧时，顺带把指示器也切到对应的State。这样演示起来完全像真实站点，开发看到原型时也能清楚地知道"指示器要和当前帧联动"。

3.3 表格与分页：用中继器承载动态数据

表格是B端Web项目里最高频的组件，没有之一。如果只是画一个静态表格，列表页演示起来其实也还行，但一旦涉及排序、分页、选中、筛选，静态表格就完全撑不住了。这也是我在Axure组件库里坚持用中继器做表格的原因。

中继器在Axure里的地位有点像前端里的数据数组。你可以把表数据放在中继器的数据集里，每一行就是一条记录，然后在"每项加载"事件里把数据集里的值填充到列表格的对应文本中。比如数据集里有name、owner、progress三个字段，中继器模板里放三个文本框，每项加载时分别Set Text到这三个文本框。这样中继器里有多少行，表格就渲染多少行；你再配合中继器的排序、过滤、分页功能，就能够实现非常接近真实系统的表格交互。

分页器我自己是做成一个单独组件，和中继器配合使用。分页器里放"上一页、页码按钮、下一页"，中间页码按钮用动态面板做当前页高亮。点击页码时，先把中继器翻到对应页，再把页码按钮的高亮状态切过去，顺便更新"共x条/第x-x条"的统计文本。这套逻辑说起来复杂，但只要做一次组件封装，之后每个列表页都是拖分页器、填数据、绑事件三步走，效率提升非常明显。

还有一个容易被忽略的状态是表格空态。真实业务里列表查询结果为空是常态，原型里如果不画空态，开发不知道是要"给个空白表格"还是"放一个暂无数据插画"。我的习惯是给中继器加一个"No Data"判断：如果数据集的行数为0，显示一个空态面板；否则显示表格主体。这个逻辑可以用中继器的添加排序或交互条件来做，虽然稍微有点绕，但对高保真完整度来说很值。

3.4 弹窗与抽屉：遮罩、层级和关闭策略

弹窗和抽屉这种浮层组件，看起来只是"显示/隐藏"两个动作，但真做起来细节不少。第一个细节是遮罩。弹窗出现时通常页面背后要盖一层半透明遮罩，用来阻隔点击和集中注意力。在Axure里我会先把遮罩做成一个动态面板，背景色用黑色+透明度40%，然后把它和弹窗内容区一起放进一个"浮层容器"动态面板里。浮层容器初始状态设为隐藏，需要弹窗时显示出来。

第二个细节是关闭策略。很多原型里弹窗只有一个关闭按钮，但实际Web产品往往还有"点击遮罩关闭""按ESC关闭"。如果要高保真，我是建议把点击遮罩关闭也做进去：在遮罩上添加"鼠标单击时→隐藏浮层容器"的事件，这和真实前端的maskClosable属性是对应的。有些业务弹窗不允许点击遮罩关闭，比如支付确认弹窗，那你在原型里就不给遮罩加关闭事件，同时还要在说明里标注"此处遮罩不可关闭"，开发就能精确对齐。

第三个细节是层级。多个弹窗叠加时，后弹出的弹窗应该盖在前一个上面。Axure里的实现方式是利用动态面板的排列顺序，或者通过"置顶"操作来调整浮层的显示顺序。我一般会在组件说明里写清楚：每个浮层容器需要放在页面所有内容的最上层，如果弹窗A打开后再打开弹窗B，需要把B容器置于A容器之上。这个细节虽然小，但是多人协作时经常被忽略，导致演示时弹窗被页面内容盖住。

抽屉的逻辑和弹窗类似，只是出现方式多了一个"滑入滑出"动画。Axure动态面板在切换状态时支持各种方向滑动动画，比如抽屉从右侧滑入，就在显示动态面板时选择"进入动画-向右滑动"之类的选项。这里的关键是，动画的方向要和抽屉的实际位置一致，否则会出现抽屉从天上掉下来的诡异效果。演示给业务方看时，这种动画细节对"高保真感"的贡献非常大。

4. 把交互做扎实：状态切换与组件通信

4.1 每个组件都要备好一套"状态集"

高保真和低保真最本质的差别，就是高保真把组件的状态集画全了。我在做组件库时会强制自己为每个交互组件列一张状态清单，清单上不列满就不允许收工。

拿最基础的按钮来举例，状态集至少是：

这五个状态里，前三个我建议直接用Axure的"交互样式"来做，就是给元件添加鼠标悬停样式、鼠标按下样式。这样做成本最低，而且切换很自然。但"禁用"和"加载中"这种业务状态，单纯用交互样式做不了，需要用动态面板来承载。所以我一般把按钮做成动态面板，State1是默认/悬停/按下，State2是禁用，State3是加载中，然后通过事件在状态间切换。表单输入框也是一样，默认态、聚焦态、错误态、禁用态，至少四个状态要完整。

很多刚接触高保真的人会觉得这样工作量翻倍了，但实际上一次的投入可以在几十个页面里反复使用。而且我自己的体会是，当你把状态集列出来之后，很多业务上的边界问题在原型阶段就暴露了。比如"登录按钮点击后到底要不要进入加载中？失败之后按钮恢复成什么状态？"这些问题开发也会问，你现在回答，总比开发写了一半再问要好得多。

4.2 组件通信：购物车数量如何跨页面联动

Axure里经常遇到一种需求：A页面里操作一个组件，B页面的另一个组件要跟着变化。这其实就是原型层面的"组件通信"，跟前端里的父子组件传值、全局状态管理是一个道理。Axure虽然没有真正的组件实例和事件总线，但用全局变量加上页面载入事件，基本能覆盖大多数场景。

我拿一个最常见的购物车角标来拆解。需求是：每个商品卡片上有个"加入购物车"按钮，点击后页面顶部的购物车图标角标数字要加1；切到购物车页面后，列表里要能看到刚才加的商品。实现方式是这样的：先在"项目全局变量"里定义一个变量cartCount，初始值为0。然后给商品卡片上的"加入购物车"按钮添加事件：鼠标单击时，设置全局变量cartCount = [[cartCount + 1]]，同时把顶部导航母版里的角标文本Set Text为[[cartCount]]。因为顶部导航是母版，所有页面共用，所以这个角标在操作发生的当前页面会立即更新。

切到购物车页时，需要让购物车列表也显示新加的商品。我的做法是在购物车页面的"载入时"事件里，用中继器的Add Rows往购物车数据集中插入一行，数据来源可以是全局变量存下来的商品ID和名称。这里有一点要特别注意：全局变量在Axure里是跨页面持久化的，所以只要你不刷新浏览器，切页之后变量值不会丢。这就实现了跨页面的数据联动。

如果组件之间的通信是同一个页面里的，那就更简单了。比如列表页选中多行后，底部的"批量删除"按钮变成可点状态，并且按钮旁边的文本显示"已选x项"。这些都可以用"点击行切换选中样式 + 更新全局变量 + Set Text"来实现。核心思路就是：任何组件之间的状态同步，都靠全局变量做中间人，再用文本或动态面板状态把变量的变化渲染到界面上。这个思路想通之后，Axure里的组件通信基本就是套公式。

4.3 用例逻辑：让组件从"会动"变成"懂业务"

高保真组件能切换状态，只是第一步；真正让原型看起来"懂业务"的，是组件上叠加的条件逻辑。Axure里用用例(Case)和条件判断来承载这种逻辑，一个事件下可以挂多个Case，Axure会从上到下依次判断条件，命中哪个就执行哪个。

举一个登录表单的例子。点击登录按钮时，真实业务的判断顺序是这样的：先看用户名是否为空，为空就显示"请输入用户名"的错误提示，中止流程；再看密码是否为空，为空就显示"请输入密码"的错误提示；再看密码格式是否符合要求；最后才调用登录接口，期间按钮进入加载中，如果登录失败显示服务端返回的错误信息。这套逻辑在Axure里完全可以复现。我给登录按钮添加"鼠标单击时"事件，加三个用例：Case1如果用户名文本框的内容为空，则显示用户名错误提示；Case2否则如果密码为空，则显示密码错误提示；Case3否则执行登录成功的跳转。实际项目里还可以加"加载中"状态和失败分支，无非是Case多几个罢了。

这样做的价值，很多人低估了。你把这个逻辑在原型里完整跑通，开发拿到的就不再是一张静态图，而是一个"可视化的业务规则说明书"。我在一些项目里甚至让开发和测试直接照着原型的用例写测试用例，因为异常分支都已经在原型里跑过一遍了，漏掉的边界情况反而更容易被发现。当然，也不是所有组件都要写这么深的逻辑，我的原则是：核心业务流程、涉及校验和状态流转的组件，一定要有逻辑；纯展示类的组件，保持轻量就好。

5. 组件库如何反哺前端：交付物与命名映射

5.1 把Axure组件和前端组件库一一对应

做组件库最大的隐形收益，是对齐前端。现在稍微成熟一点的Web团队，基本都会用Element UI、Ant Design、Vant这类现成的前端组件库。你在Axure里画组件的时候，如果能主动朝前端组件库的规格靠，后面开发和设计之间的"翻译成本"会低很多。

我的习惯是，在组件库里专门建一个"Mappings"页面，把Axure组件和前端组件放成一张对照表。比如Axure里的dialog_btn_primary对应Element UI的el-button type="primary"，Axure里的table_pagination对应前端组件库的el-pagination，Axure里的级联选择器对应Vant的级联选择组件。每一条映射里，除了名字对应，还要写清楚差异点，比如"Axure里弹窗宽度定的是480px，前端组件库默认宽度可能不同，需要以原型标注为准"。

为什么要做这件事？因为原型最终是要被开发还原成代码的。如果原型里的组件结构和前端组件库完全脱节，开发就得从零复刻一套样式，既慢又容易跑偏。反过来，如果原型组件在尺寸、状态、交互细节上本来就参考了前端组件库，开发在写代码时几乎可以"照抄"组件库的API，保持一致性的成本大大降低。我在项目里发现，这种映射表做得越细，还原度越高，开发跟产品之间的争议也越少。

这里还要提一个热词里反复出现的"组件通信"。很多前端组件库的组件之间存在事件交互，比如父组件向子组件传值、子组件向父组件发消息。你在Axure里设计组件时，也最好把这种数据流在命名和注释里体现出来。比如一个表单组件，我会注明"提交按钮点击后，需要把表单数据传给全局变量formData，再由详情页读取展示"。这样开发在接前端组件通信时，思路会非常清楚。

5.2 标注、说明和切图：开发最需要的三件套

很多产品经理觉得Axure原型的注释标注是多余的，反正开发能看懂页面。我一开始也这么想，直到有开发因为间距差2px来来回回问我三次之后，我彻底改了这个习惯。现在我交付原型时，除了页面本身，一定会附上三样东西：标注说明、交互说明表、关键切图资源。

标注说明我通常放在每个页面的右侧空白区，用编号和引线指到对应的组件位置。标注里只写开发真正需要的东西：宽度高度、内边距、圆角、字号、色值、间距。如果组件是从样式底座取的值，我会直接写"颜色取自主色，见样式规范页#1"，而不是每个地方都复制一遍色号，这样也方便后续统一改色。

交互说明表是另一个好用的工具。我常用的格式是：序号 | 触发元素 | 触发方式 | 交互反馈 | 跳转目标 | 异常分支。拿弹窗举例：

这张表比原型页面本身更值钱，因为它是交互逻辑的结构化表达，测试可以直接拿它转测试用例，开发可以直接拿它写分支逻辑。

切图资源这块，Axure原生的导出能力没那么强，但组件库里的通用图标、Logo、插画，我一般会让设计师从设计稿里导出SVG放到原型对应的文件夹里，开发需要的时候直接取用，不用再从原型里截图抠图。图标在原型里能用SVG就尽量别用位图，放大缩小不变形，演示效果也更好。

5.3 用版本记录沉淀决策，而不是靠口口相传

组件库不是做完一次就结束的东西，它会随着业务迭代不断变化。今天改导航的间距，明天给表格加一个行内操作按钮，后天又调整按钮圆角。这些改动如果不做版本记录，一个月后你很难说清楚当前组件库到底哪一版是"权威版本"，前端更不知道应该对齐哪个版本。

我自己的做法是，在组件库里放一个"Change Log"页面，每一行记录一条变更，字段包括：版本号、日期、变更内容、影响范围、前端是否已完成同步。版本号我习惯用V1.0、V1.1这种，大版本跳号时意味着有破坏性改动，比如整体换了主题色，这种改动不仅要记录，还要提前一周告诉前端和所有用组件库的人。小版本改动就只是细微调整，记录一下即可，前端同步后打个勾，避免后面扯皮。

另外有一点很重要：组件库文件的命名也要带版本号。不要出现"最终版""终极版""打死不改版"这种文件命名，团队协作里这就是灾难。我一般是web_components_v1.2.rp这种命名，每次改动另存为新版本文件，旧的留档，万一新版本改崩了还能回退。这个方法我在多个项目里都验证过，成本极低，但带来的安全感很高。

6. 踩坑记录与提效技巧：版本、性能和多人协作

6.1 性能问题：动态面板不是越多越好

高保真组件做多了，Axure文件会越来越卡，这个坑我踩得特别深。有一年我做一个大型B端项目，原型里到处是动态面板，轮播图、下拉菜单、弹窗、Tab切换全用动态面板，结果预览页面要等好几秒才能打开，演示现场特别尴尬。后来我总结出一个规律：动态面板虽然能做状态切换，但它不是不用成本的。每个动态面板在预览时都要额外计算当前显示哪个State，页面里动态面板数量多了，性能自然下降。

所以我现在的组件库里有一个明确的分层：简单的视觉状态变化，尽量用Axure的交互样式，也就是悬停、按下、选中等样式切换，不用单独占用动态面板。复杂的业务状态，比如表单的加载中、表格的空态、弹窗的显示隐藏，才用动态面板承载。能不用动态面板的地方，坚决不用。

中继器也是一样的道理。中继器能模拟动态数据，但它本质上是一个循环渲染列表，数据量越大，预览越卡。我在原型里一般把中继器的演示数据控制在50行以内，超过50行就用"查看更多"的分页逻辑来模拟，而不是真的放几百行数据进去。图片资源方面，原型里的位图尽量压缩后再导入，能用SVG的图标优先用SVG，这些习惯都能让原型保持流畅。

6.2 多人协作的组件库维护：权限、更新通知与回归

组件库发展到一定规模，往往是产品团队、交互团队、UI团队一起维护。这时候最大的风险不是没人做组件，而是每个人都改了一版组件库，最后不知道以谁为准。我在实践里吃过亏，所以现在会明确几条协作规则。

规则一是"一个Owner"。组件库必须有一个明确的负责人，其他人可以提交建议、可以答疑，但一切组件库元素的增删改都得经过这个Owner。Owner的职责是保证命名一致、状态完整、风格统一，同时负责对外发布更新通知。这个角色不一定是很资深的人，但一定要有维护组件的责任心。

规则二是"改动必通知"。每次更新组件库，都要在那个Change Log页面里写清楚，并且在项目群发一条简短通知，列出版本号、改动点、是否需要页面重新引用。为什么一定要通知？因为Axure的母版在页面里默认是"跟随母版更新"的，但你如果改的是动态面板内部的结构，已经放置的实例不一定能自动更新干净，需要手工重新拖入或者重置母版实例，所以必须让大家知道"这里需要动一下"。

规则三是"大改必回归"。如果组件库做了大版本改动，比如换了全套间距规范，那就需要抽查核心页面，包括首页、列表页、详情页、表单页，确认这些页面的视觉和交互没有因为组件更新而出问题。这个回归不一定要很重，但必须做一遍，否则很有可能出现"C页面按钮正常，D页面按钮错位"这种问题。

6.3 提高效率的小习惯：模板页、自定义元件库和克制的高保真

最后分享几个我这些年攒下的关于Axure效率的小习惯，每一个都算不上复杂，但加起来能省很多事。

第一个习惯是创建"模板页"。组件库之外，我会再维护一套完整的模板页面，比如带侧边栏的标准后台布局、带顶部导航的营销页布局、移动端列表页布局。新项目启动时，直接复制这套模板页作为画布，把Logo、菜单、模块换成新业务的，半天就能跑出一个高保真的雏形。比从空白页面开始画不知道快了多少倍。

第二个习惯是用Axure的自定义元件库。把做好的组件拖进一个.rplib文件，然后在"元件库"面板里加载它。这样你在任何新项目里都能像用Axure自带元件一样，从库里把组件拖到画布上。而且元件库支持团队共享，大家用同一个元件库，才能保证所有原型的风格基本一致。

第三个习惯是克制高保真的范围。不是所有页面都值得做到同样的高保真度。我的取舍标准是：核心业务链路、需要用户评审的页面、开发容易理解错的复杂交互，一定要高保真；而像隐私协议、数据公告、纯文本展示这类页面，用线框图或者占位说明就可以了。这样既保证了关键体验的原汁原味，又不会让组件库的维护成本把自己拖垮。

最后还想提一点：组件库是需要养长期主义的，它不是一次画完就束之高阁的模板，而是每做一个新项目、每经历一次真实反馈，都值得回过来补一补、改一改的活资产。我每次做完项目复盘，都会把交互说明表里那些"当时没想到的异常分支"补到组件库里，下次再做类似需求时，组件库就比上一次更厚实一点。这大概也是Axure高保真Web开发常用组件这件事，最让我觉得值得持续做下去的原因。