Axure RP 9 使用详解：从表单控件到动态面板的交互原型实战

简介：《Axure RP 9 使用详解》面向原型设计初学者、产品经理以及需要提升演示效果的开发人员，针对只会画静态图、备注堆叠、难以向客户展示等问题，系统梳理 Axure RP 9 的常用操作与进阶交互，帮助缺少系统训练的设计者建立规范的操作框架。压缩包共 1 个 docx 文档，约 2.54MB，内容以图文说明和操作要点为主，便于按章节查阅、对照练习与随用随查，适合边学边练。已有 6587 人学习，说明其覆盖的知识点具有较强参考价值。文档从页面简介与工具栏讲起，延伸到元件样式、部件库、下拉列表、文本框、热区、动态面板、内联框架、水平与垂直菜单及隐藏显示设置，并涉及函数运算、图形外显批注、取色工具和 HTML 演示文件生成；读者可据此理解交互原型的搭建思路，减少备注堆叠带来的沟通障碍，提升投标演示、团队协作和开发交接中的表达效率。

1. 客户问“这个按钮点下去会怎样”时，你手里的原型能回答吗

投标现场最容易出问题的一幕，是客户指着界面问“这个按钮点下去会跳哪”，而你只能把鼠标停在批注框上，把备注念一遍。装完 Axure RP 9 的人不少，能做出可演示原型的却不多——大部分原型停在“静态截图 + 密密麻麻的说明”，评审一放大就显得准备不足。这份《Axure RP 9 使用详解》docx 走的是另一条路：从页面和工具栏讲起，把下拉列表、文本框、多选、悬浮说明、内链框架、显隐顺序、水平/垂直菜单、热区、动态面板、交互、函数、批注、取色，一路铺到演示文件生成。它不是讲配色和排版的设计书，而是一份按操作顺序排下来的手册，适合刚接手原型任务的产品和设计新人，也适合需要拿原型跟客户、开发对齐的售前和开发。它要解决的问题很单一：让原型自己会说话。

2. 主界面、部件库与命名：先让元件“找得到”再谈画得好

拿到一份原型文件，最怕的不是画得丑，是打开之后找不到东西。左侧页面树里躺着十几个“Page 1”“Page 2”，画布上一个按钮叠着三个透明热区，点开交互面板全是“OnClick of Rectangle 12”。这种文件自己改都费劲，更别说交给同事接手或者拿去演示。这一章先把工作区、样式基线和命名这三件基础的事情定下来，后面所有控件和交互才有地方落脚。这份 docx 把“页面简介”“工具简介”“设计主界面及命名”放在最前面，顺序是对的——原型不是画出来的，是组织出来的。

2.1 三大工作区的分工与页面树命名

Axure RP 9 的界面可以粗暴地切成三块：左边是资源区，包含 Pages（页面）、Outline（大纲）、Masters（母版）和 Widgets（部件库）；中间是画布；右边是 Inspector 面板，分 Properties（属性）、Style（样式）、Interactions（交互）和 Notes（说明）四页。新手常犯的错是把所有东西都往画布上堆，页面树不整理，母版不用，结果每加一个页面就复制粘贴一遍导航栏，改一次 logo 要改二十处。

页面树我一般按“编号_模块_状态”来命名，编号保证排序稳定，状态拆出正常态和异常态，方便演示时直接跳到对应页面：

元件命名同样要立规矩：按钮用btn_前缀，输入框用txt_，下拉用ddl_，动态面板用dp_，热区用hs_，内链框架用frame_。这样在交互面板里选目标元件时，下拉列表是有序的，不用在一堆Rectangle里靠位置猜。母版（Master）用来装全局导航、页脚、弹窗骨架这类重复元素，改母版等于改所有引用它的页面，这个习惯能省掉后期大量返工。

提示：页面尺寸在画布空白处点一下，右侧 Properties 里能改。默认 1024×768 偏窄，做后台系统建议直接按 1440×900 起，演示时缩放比例更接近真实浏览器。

2.2 原件样式与图标：四组参数定住视觉基线

原型的视觉不需要多漂亮，但必须一致。同一个页面里三个按钮三种圆角、两种字号，客户第一眼就会觉得“这东西没做完”。Axure 的 Style 面板把可控项拆得很细，实际只需要盯住四组：

图标这块，docx 里提到“原件样式、图标及交互属性”，实操上最省事的做法是用 Axure 自带的 Icons 部件库，拖进来直接是矢量形状，能改颜色能缩放；外部 SVG 也可以直接拖入画布，导入后右键“Convert to Shapes”就能当普通形状编辑。不建议用位图图标，缩放一次就模糊，演示投到大屏上尤其明显。

样式定完之后，把它存成默认样式：选中一个调好的元件，Style 面板顶部有“Default Style”入口，保存后新建的同类元件直接继承。这个小动作能省掉大量重复调参。

2.3 交互属性面板：每个元件都该有的默认动作

Interactions 面板是 Axure 的核心，结构是“事件 → 动作 → 条件”。事件是触发源，动作是结果，条件是判断分支。高频事件就那么几个：

动作里有几个必须提前建立认知：Open Link负责页面跳转和框架内跳转，Set Panel State负责动态面板切换，Show/Hide负责显隐并可以顺带调整层级，Set Selected负责选中态，Set Text负责改文字，Set Variable Value负责写全局变量。条件判断通过Add Condition添加，可以判断元件文字、选中状态、变量值、甚至表达式结果。

我的习惯是：任何需要被别的元件引用的元件，先命名再写交互；任何交互，先想清楚“点完之后用户看到什么变化”，再决定用哪个动作。顺序反了，就会写出一堆点了没反应的死交互。

3. 表单控件落地：下拉列表、文本框、多选与悬浮说明

演示里被问得最多的永远是表单。“这个下拉能不能多选”“手机号输错了会提示吗”“这个字段为什么是灰的”，这些问题靠嘴解释没有说服力，靠控件本身的状态变化才有。这一章把 docx 里 3.2 到 3.7 的内容拆开落地：下拉列表、文本框、多选、悬浮说明、隐藏显示顺序，每一个都给出可复现的操作路径和参数建议。

3.1 下拉列表：选项、默认值与“假禁用”

Axure 的 Droplist 部件本身很简单，双击元件或者在 Properties 面板里点Edit Items就能加选项，Set Default指定默认选中项。它的短板是只有显示文本、没有独立的值字段，也没有真正的禁用态。所以在需要“值”的场景里，通常用两种办法绕：一是用[[This.text]]直接取选中文本，二是在选项文本里用“显示文本|值”的约定，交互里用字符串函数切分。

联动是下拉列表最常见的需求。做法是给第一个下拉加Selection Changed事件，在里面按选中值做条件分支，再给第二个下拉Set Text或者用动态面板切换不同的选项组。比如城市选择，一级选“华东”，二级就切换到“上海/杭州/南京”那一组。

“禁用态”需要自己模拟：在下拉上方盖一个和背景同色的矩形，透明度调到 10% 左右，加一个Click事件弹出一句“当前不可修改”的提示，视觉上再改一下下拉的文字颜色。评审时客户点一下就有反馈，比嘴上说“这里不能选”强得多。

注意：Droplist 的选项文本里不要带换行和特殊符号，部分浏览器生成 HTML 后会截断，演示时选项显示不全，很容易被当成 bug。

3.2 文本框：输入类型、提示文字与失焦校验

Text Field 的 Properties 里有几个参数值得逐个设：Type决定输入类型（Text、Password、Email、Number、Phone、URL 等），Hint Text是空值时显示的灰色提示，Max Length限制字符数。移动端原型务必把手机号设成 Phone、密码设成 Password，演示时输入内容会被自动处理，观感差别很明显。

校验是文本框最有说服力的部分。做法是在Lost Focus（失焦）事件里加条件判断，不满足就显示错误提示：

• 条件一：Widget text of txt_phone等于空 → 显示“请输入手机号”
• 条件二：length of Widget text of txt_phone小于 11 → 显示“手机号格式不正确”
• 都不满足 → 隐藏错误提示，边框恢复默认色

错误提示本身建议做成一个默认隐藏的矩形加文字，命名tip_phone_error，和输入框左对齐、间距 4px，出现时把输入框边框改成红色。这个组合在评审里几乎百试百灵，因为它把“校验”这件抽象的事变成了可见的变化。

输入框获得焦点时的样式也顺手加一下：Focused事件把边框颜色改成主色，Lost Focus改回来。成本很低，但演示时的精致感提升明显。

3.3 下拉多选与原件悬浮说明的配合

Axure 的 List Box 支持多选，在 Properties 里勾上Allow Multiple Selection就行，但它长得像个展开的列表框，不像下拉。想要“点一下展开、勾完收起”的效果，标准做法是用动态面板自绘：面板里放一组复选框（Checkbox），主控元件点击时切换面板的显示状态，选中的项数用Set Text回写到面板外的显示框里。

多选场景最容易出问题的是“已选数量”的显示。简单的做法是给每个复选框的Selected事件加一次计数变量累加，取消选中就减一，最后把变量写到显示文本里。复杂一点可以用[[LVAR1.text]]配合字符串拼接，但演示原型不建议做太重，数量对得上就够。

原件悬浮说明（docx 里的 3.5）本质是提示气泡。做法是准备一个带圆角和阴影的矩形，命名tip_common，默认状态下在 Style 面板勾选Hidden；给需要说明的元件加Mouse Enter事件，动作为Show tip_common，同时用Move动作把提示框移动到光标附近；Mouse Exit里再Hide。移动的坐标可以用Cursor.x和Cursor.y做偏移，避免提示框正好盖住鼠标导致闪烁。

表格里放一下这几个控件的关键设置，方便对照：

3.4 隐藏、显示与显示顺序：让图层堆叠可预期

Show/Hide这个动作看起来简单，实际有三个开关会影响结果：动作本身是 Show、Hide 还是 Toggle；显示时是否Bring to Front；隐藏时是否Send to Back。做弹层的时候，如果只 Show 不置顶，弹层很可能被后画的元件压住，点了没反应——这几乎是新手排查时间最长的一类问题。

“显示顺序”在 docx 里单独列了一节，是有道理的。画布上的元件按添加顺序堆叠，后加的在上层。要调整顺序，除了动作里的置顶置底，还可以用顶部 Arrange 菜单里的Bring to Front、Send to Back、Bring Forward、Send Backward。我的习惯是：结构性的层级（背景、内容、弹层、提示）在命名阶段就用前缀区分开，弹层统一用layer_开头，排错时在 Outline 面板里一眼就能看出谁压着谁。

还有一个参数容易被忽略：Show动作里的Push/Pull Widgets。勾上之后，显示或隐藏元件会把下方内容顶开或拉回；做折叠面板时这个很好用，做普通弹层时一定要关掉，否则一弹窗整个页面布局就乱。

4. 导航与交互：菜单、热区、内链框架、动态面板与函数

前两章解决的是“单个元件怎么摆”，这一章解决“页面之间怎么串”。原型的说服力八成来自流程能不能走通：点菜单能切页、点卡片能进详情、点返回能回来、右键能出菜单。docx 里 3.8 到 3.13 这几节正好覆盖了这条链路，下面按实际搭建顺序拆开说。

4.1 水平菜单与垂直菜单的选中态

菜单的难点不在画，在“选中态只能有一个”。手工做法是给每个菜单项加Click事件，把自己设为选中、把其他项设为未选中，写四五个菜单就要写四五组动作，改一次菜单要重写一遍，非常麻烦。Axure 9 提供了选中组（Selection Group）机制：把一组菜单项同时选中，右键设为同一个 Selection Group，之后给每项加Click事件，只需要Set Selected → This → True，同组其他元件会自动取消选中。

选中态的视觉用 Style 面板里的Selected状态来定义：选中时改背景色、文字颜色、加左侧指示条。这样交互只负责状态切换，样式负责表现，两者不混在一起。水平菜单和垂直菜单的做法完全一样，区别只是排列方向和对齐方式，垂直菜单记得给每项设成等宽，否则文字长度不一会参差不齐。

菜单项数量和文字建议在纸面上先定好，原型阶段频繁改文案，会让后面所有引用它的交互重新选目标元件。

4.2 内链框架的命名、嵌入与跳转

内链框架（Inline Frame）是“页面里嵌页面”的元件，后台系统原型几乎绕不开它：左边菜单固定、右边内容区随菜单切换，就是靠框架实现的。docx 里特别强调“先选中框架，然后给他命名”，这个顺序不能反——框架不命名，交互里就没法指定“在哪个框架里打开”。

操作路径是：拖入 Inline Frame → 右侧 Properties 里把Name改成frame_content→Target Page选一个默认页面（比如首页）→ 给菜单项加Click事件 →Open Link→ 选择目标页面 → 在打开方式里选Frame，下拉里选中frame_content。

框架还有两个参数要调：尺寸要和目标页面的宽度匹配，差太多会出现横向滚动条；Hide Scrollbars按需勾选，内容型页面建议保留纵向滚动，演示时能体现内容多少。跨页面传值的场景，用全局变量中转：在Project → Global Variables里建一个变量，源页面Set Variable Value写入，目标页面Load事件里Set Text读出来。

提示：框架里嵌入的页面如果本身还有框架，很容易出现三层嵌套导致滚动条打架。演示用原型建议控制在一层嵌套以内。

4.3 热区：不规则点击区域的兜底

热区（Hot Spot）是一个透明元件，本身不可见，只负责接收点击。它的价值在两个场景：一是点击区域和视觉形状不一致，比如一张不规则的产品图、一个带图标和文字的组合卡片，直接给图片加点击只有图形部分能点中；二是需要扩大点击范围，移动端原型里按钮太小不好点，盖一个比按钮大一圈的热区，演示时手感立刻不一样。

用热区有一个铁律：它必须在最上层。热区是透明的，被其他元件盖住之后完全点不到，而且从画布上根本看不出来问题出在哪。排查这类问题的办法是打开 Outline 面板，按层级从上往下看，热区应该排在它所覆盖的元件上方；或者临时给热区填个半透明色，确认位置后再改回透明。

热区的形状可以改，矩形、圆形、自定义多边形都支持，配合图片做不规则区域的点击很合适。命名统一用hs_前缀，并且加 Notes 说明它对应哪个元件，过一周回来改也不至于忘。

4.4 动态面板的多状态切换与右键效果

动态面板（Dynamic Panel）是 Axure 交互的核心，本质是一个可以装多个状态（State）的容器，同一时刻只显示一个。docx 里写“双击给不同的动态面板设置不同的展示界面”，说的就是双击面板顶部切换 State 进行编辑。

搭建步骤大概是：拖入动态面板 → 双击进入编辑 → 在 State 面板里Add State增加状态 → 每个状态里放不同的内容 → 退出后用Set Panel State动作切换。切换动作里有三个参数要选：目标状态（可以是具体某个 State，也可以是Next、Previous）、动画效果（Slide Left/Right、Fade、Push 等）、是否Wrap（循环）。选项卡、轮播图、折叠面板、弹窗，全是这一套。

右键菜单的做法是给目标区域加Context Menu事件，动作为Show一个预先做好的菜单面板，位置用Move动作跟到光标处；点击页面其他区域时再Hide。这里有个体验细节：菜单弹出位置要判断是否会超出画布边缘，靠右的卡片弹出菜单时应该向左偏移，否则菜单会被裁掉，演示时很尴尬。

4.5 函数表达式在显隐和文本上的用法

Axure 的函数写在双方括号里，语法接近 JavaScript，可以用来做动态文本、条件判断和简单的数值计算。docx 里把“函数”单独列了一节，是因为它能把“死原型”变成“有反馈的原型”。

常用的几类：

一个具体例子：做一个“剩余字数”提示。给文本框txt_desc加Text Changed事件，Set Text到提示元件，值写[[100 - txt_desc.text.length]]，超过 100 时用条件判断把提示文字改成红色。整个逻辑不复杂，但演示时客户一边打字一边看到数字变化，对“这个原型是活的”这件事的感知会明显不同。

函数最容易翻车的地方是变量名拼错和作用域搞混。局部变量（LVAR）只在当前动作里有效，跨页面传值必须用全局变量，而且全局变量要先在项目设置里建好。表达式写错时，预览里通常直接显示原始字符串或者空白，不会报错，所以每加一个表达式都要在预览里点一遍验证。

5. 常见问题排查：五个让演示当场翻车的细节

原型做完自己点一遍都正常，换台电脑、换个浏览器、投到大屏上，问题就冒出来了。这一章列的五个坑，基本覆盖了演示现场八成以上的意外，每一条都按“现象 → 原因 → 解决”写，遇到时可以直接对照。

现象一：点了按钮完全没反应，检查交互明明写了。原因通常是元件被上层透明元件挡住，最常见的是热区、透明矩形或者没隐藏的提示层。Axure 的点击事件只传给最上层元件，被盖住之后就收不到。解决办法是打开 Outline 面板从顶层往下排查，把所有透明元件的层级理一遍；临时把可疑元件填成半透明色，点不到的位置会立刻现形。修完之后养成习惯：热区和提示层这类透明元件，统一在命名里带layer_前缀，方便一次性排查。

现象二：页面跳转正常，但返回后动态面板回到了初始状态。原因是动态面板每次重新载入都默认显示第一个 State，跳走再回来不会记住上次的状态。解决方式有两种：一是在面板所在页面的Load事件里主动Set Panel State到指定状态；二是用全局变量记录当前状态编号，载入时按变量值切换。前者适合固定入口，后者适合多入口共用一个页面。选项卡类组件尤其要注意，演示时切到第三个 tab 再跳走回来，tab 回到第一个，客户会以为点错了。

现象三：生成的 HTML 在别人电脑上打开，图片裂了、图标变方块。图片裂开多半是生成时引用了本地绝对路径，文件拷到别的机器上找不到源图。生成演示文件时要选一个干净的输出目录，让 Axure 把资源一起打包进去，不要只拷index.html一个文件。图标变方块通常是图标字体没随包输出，生成设置里把字体相关选项勾上。最稳的验证方式是：生成后把整个输出文件夹压缩，发给另一台没装 Axure 的电脑解压打开，能正常显示才算过关。

现象四：中文文字在你的电脑上排版正常，到客户机器上字变宽、按钮文字溢出。原因是用了本机安装的第三方字体，对方机器没有这个字体，浏览器回退到默认字体，字宽变化导致布局错位。原型的字体尽量用系统自带的中文字体，或者把关键标题文字转成形状（右键Convert to Shapes），转形状后不再受字体环境影响。正文文字不建议转，改了文案就麻烦，靠统一字号和留足余量来兜。

现象五：内链框架里嵌入的页面显示不全，右边被切掉或者出现双滚动条。框架尺寸小于目标页面宽度是主因。检查两处：框架元件的 W 是否大于等于目标页面宽度，目标页面本身的页面尺寸是否设得过宽。双滚动条则是框架和目标页面都开了滚动，把框架的Hide Scrollbars勾上，只保留内容区的滚动。演示前把每个用到框架的页面都点一遍，尤其注意从菜单切过去的第一屏。

注意：这五类问题有一个共同点——在自己机器上都不复现。所以交付前一定要做一次“换机验证”，这一步省不得。

6. 生成演示文件与交付自检：把 HTML 在别人电脑上走一遍

原型做完不等于能交付。docx 最后一节讲“生产演示文件”，落到操作上就是Publish → Generate HTML Files，选输出目录、填文件名、勾选要包含的内容，点生成。参数不多，但每一项都影响对方打开时的体验。

生成之后不要急着发，先在本机双击index.html走一遍完整流程：从首页进，按演示脚本点完所有主路径，再故意触发几个异常态（空数据、校验失败、禁用按钮），确认每个交互都有反馈。这一遍走下来通常能发现三到五个问题，都是写的时候觉得没问题、点起来才发现别扭的。

第二步是换机验证。把输出目录整个压缩，发到一台没装 Axure 的电脑上解压打开，重点看四件事：图片是否完整、字体是否变形、框架内页面是否正常、右键菜单是否被浏览器默认菜单盖住。最后一项经常被忽略，部分环境下浏览器会拦截自定义右键，演示前要准备好一句话带过，别在现场反复右键。

第三步是准备一份演示脚本，按页面顺序写清楚每一步点哪里、预期看到什么。脚本不用长，一页 A4 足够，但能把演示从“即兴发挥”变成“可控流程”。脚本里把容易出问题的页面标出来，提前多走两遍。

我自己的习惯是：每次交付前强制走一遍“生成 → 本机全流程 → 换机打开 → 按脚本彩排”，四步少一步都不发。有一次省掉换机验证，客户那边打开后图标全是方块，现场只能靠截图救场，从那以后这个流程再没跳过。这份 docx 的价值也在这里——它把从页面、控件到交互、函数、生成文件的链路按操作顺序排好了，照着走一遍，能少踩很多别人已经踩过的坑。希望帮到你。

本文还有配套的精品资源，点击获取