简介：这份资源是面向Axure原型设计用户的Chrome浏览器扩展插件包，主要解决在浏览器中直接预览、调试与分享Axure原型的需求，适合产品经理、交互设计师及需要频繁演示原型的设计团队成员使用。压缩包共包含8个文件，以js脚本、png图标、json配置、html页面和txt说明为主，整体体积约25KB，轻量易部署，其中脚本负责扩展逻辑，图标与页面用于界面展示，配置文件则定义插件的基本信息。目前已有383人学习下载，说明该插件在原型设计圈内具备一定实用价值。通过安装该扩展，用户可在Chrome中实时查看Axure原型效果，减少导出与上传环节，同时便于将原型链接快速分享给团队协作讨论，并借助自定义组件与版本管理思路优化设计流程，从而提升原型迭代与团队沟通效率。
1. 从 Axure 原型到 Chrome 插件：一条被低估的交付链路
很多产品经理和交互设计师在用 Axure 做完高保真原型后，都会遇到同一个尴尬：原型只能在本地打开，发给客户或开发团队要么截图、要么导出 HTML 压缩包，对方还得手动解压、找 index 文件。更麻烦的是，当原型需要嵌入真实浏览器环境做演示时，比如要验证滚动吸顶、固定背景、响应式断点这些行为，Axure 自带的预览窗口根本模拟不准。这时候把 Axure 原型包装成一个 Chrome 插件，直接在浏览器里加载运行，就成了一条非常实用的交付路径。标题里的「axure插件」「axure谷歌插件」「chrom插件」说的其实是同一件事：让 Axure 产出的 HTML 原型以浏览器扩展的形式跑起来。它解决的是原型分发和真实环境验证两个问题，适合需要频繁给非技术方演示、或者要在真实浏览器里调试交互细节的从业者。下面我把这条链路从原理到落地拆开讲，包括怎么打包、manifest 怎么写、资源路径怎么处理，以及我踩过的那些坑。
2. 为什么要把 Axure 原型塞进 Chrome 插件里
2.1 原型分发的三种方式与各自的边界
Axure 导出原型后，常见的分发方式有三种。第一种是直接发 HTML 文件夹，对方解压后用浏览器打开 index.html。这种方式的问题是文件散落、路径容易断，而且非技术方经常找不到入口文件。第二种是上传到 Axure Cloud 或类似托管服务，生成一个链接分享。这种方式依赖网络和第三方平台，内网环境或涉密项目就用不了。第三种就是做成 Chrome 插件，通过「加载已解压的扩展程序」或打包成 .crx 文件分发。
Chrome 插件的优势在于：它是一个自包含的目录结构，加载后固定在浏览器工具栏，点击图标就能打开原型页面，不需要对方理解文件结构。而且插件运行在浏览器扩展环境里，可以访问 chrome.* API，后续想加一些增强功能，比如一键截图、页面标注、滚动位置记忆，都有扩展空间。代价是 manifest 配置和资源路径需要额外处理，这也是后面要重点讲的。
从选型角度看，如果你的原型只是内部快速评审，发 HTML 文件夹就够了。但如果原型要反复演示、要给外部客户看、或者要在真实浏览器里验证固定背景滚动这类行为，做成插件是更稳妥的选择。我一般会在项目进入高保真阶段后，同步维护一个插件版本，演示时直接加载，省去每次找文件的麻烦。
2.2 Chrome 扩展的运行机制与 Axure 产物的契合点
Chrome 扩展的核心是 manifest.json，它声明了扩展的名称、版本、权限、入口页面等。对于 Axure 原型来说，最简单的做法是把原型 HTML 作为扩展的一个页面，通过 browser_action 或 action 点击后在新标签页打开。Manifest V3 里，action 取代了原来的 browser_action，配置方式略有不同。
Axure 导出的 HTML 通常包含 index.html、resources 文件夹、data 文件夹等。这些资源都是相对路径引用，只要保持目录结构不变，放进扩展目录里就能正常加载。契合点在于：Axure 的原型本身就是纯前端 HTML/CSS/JS，不依赖服务端，天然适合放进扩展的沙箱环境。需要注意的是，Manifest V3 对远程代码执行有严格限制，如果 Axure 原型里引用了外部 CDN 的 JS 库，可能会被拦截。解决办法是把这些库下载到本地，改成相对路径引用。
另一个契合点是固定背景滚动这类效果。Axure 里设置固定背景后，导出 HTML 在普通浏览器里打开可能表现正常，但在某些缩放比例或窗口尺寸下会抖动。放进扩展后，因为扩展页面的视口行为更可控，反而更容易调稳。这也是为什么我建议在插件环境里做最终验收，而不是只看 Axure 预览。
2.3 最小可运行插件的目录结构与 manifest 配置
先给出一个最小可运行的目录结构，这是后面所有操作的基础：
axure-extension/ ├── manifest.json ├── index.html # Axure 导出的入口文件 ├── resources/ # Axure 资源文件夹 ├── data/ # Axure 数据文件夹 └── icons/ ├── icon16.png ├── icon48.png └── icon128.pngmanifest.json 的内容如下：
{ "manifest_version": 3, "name": "Axure Prototype Viewer", "version": "1.0.0", "description": "在 Chrome 中加载 Axure 原型", "action": { "default_title": "打开原型", "default_icon": { "16": "icons/icon16.png", "48": "icons/icon48.png", "128": "icons/icon128.png" } }, "background": { "service_worker": "background.js" }, "permissions": ["tabs"] }background.js 里监听 action 点击，打开 index.html：
// 监听扩展图标点击事件 chrome.action.onClicked.addListener(() => { // 在新标签页打开原型入口文件 chrome.tabs.create({ url: chrome.runtime.getURL('index.html') }); });这段配置的逻辑是：manifest 声明了一个 action 和一个 background service worker。当用户点击扩展图标时，background.js 里的监听函数触发，调用 chrome.tabs.create 打开扩展目录下的 index.html。chrome.runtime.getURL 会把相对路径转成扩展的绝对 URL，这是 Manifest V3 里访问扩展内资源的正确方式。
参数说明：manifest_version 必须写 3，Chrome 已经逐步淘汰 V2。permissions 里只加了 tabs，因为需要创建新标签页。如果后续要加截图功能，还需要加 activeTab 或 scripting 权限。icons 尺寸建议准备 16、48、128 三个，缺省时 Chrome 会用默认图标，但看起来不专业。
把 Axure 导出的所有文件复制到这个目录里，确保 index.html 在根目录。然后在 Chrome 地址栏输入 chrome://extensions，打开开发者模式，点击「加载已解压的扩展程序」，选择 axure-extension 文件夹。加载成功后，点击工具栏上的扩展图标，就能在新标签页看到原型了。这一步跑通，后面才有优化空间。
3. 把 Axure 导出物改造成插件可加载的完整步骤
3.1 导出 Axure 原型时的三个关键设置
在 Axure 里导出 HTML 之前，有几个设置直接影响后续能不能顺利加载。第一个是「生成 HTML 文件」时的输出路径，建议单独建一个空文件夹，不要和源文件混在一起。第二个是「页面」选项卡里的「包含页面说明」和「包含 sitemap」，如果不需要可以取消，减少文件体积。第三个是「移动端」相关设置，如果原型是桌面端，确保视口设置是默认的，不要勾选移动端适配，否则导出的 HTML 会带 viewport meta 标签，在扩展页面里可能导致缩放异常。
导出完成后，打开导出的文件夹，确认 index.html 存在，并且用浏览器直接打开能正常显示。这一步是基线验证，如果直接打开都有问题，放进扩展里只会更麻烦。我遇到过 Axure 导出时资源路径用了绝对路径的情况，比如 src="/resources/xxx.js"，这种在扩展里会加载失败，因为扩展的根路径不是文件系统根路径。解决办法是在 Axure 的「发布」设置里，把「HTML 文件路径」改为相对路径，或者导出后手动批量替换。
另一个容易忽略的点是字体文件。Axure 原型如果用了自定义字体，导出后会在 resources 里生成字体文件，通过 @font-face 引用。这些引用通常是相对路径，放进扩展没问题。但如果字体是从 Google Fonts 等外部地址加载的，Manifest V3 的 CSP 会拦截，需要把字体下载到本地并改写 CSS。
3.2 处理 Axure 资源路径与 Manifest V3 的 CSP 限制
Manifest V3 的内容安全策略（CSP）默认禁止加载远程脚本和远程样式。Axure 导出的 HTML 里，如果引用了 jQuery、Axure 运行时等，通常是本地文件，这没问题。但有些第三方组件，比如某些图表库，可能会从 CDN 加载。检查方法是打开 index.html，搜索 http:// 和 https://，看有没有外部引用。
如果有，处理方式分两种。对于 JS 库，下载对应文件放到 resources 文件夹，然后把 script 标签的 src 改成相对路径。对于 CSS 里的字体或图片引用，同样下载到本地并改写 url()。改完后，在扩展里加载，打开开发者工具的 Console，看有没有 CSP 报错。常见的报错是「Refused to load the script because it violates the following Content Security Policy directive」，看到这个就说明还有远程引用没处理干净。
还有一种情况是 Axure 原型里用了 eval 或 new Function，这在 Manifest V3 里也会被 CSP 拦截。Axure 本身生成的代码一般不会用 eval，但如果你在原型里嵌入了自定义 JS，就要检查一下。解决办法是改写代码，避免动态执行字符串。如果实在改不了，可以考虑把原型页面放在一个 iframe 里，iframe 的 src 指向扩展内的 HTML 文件，这样 CSP 的限制会宽松一些，但也不是完全绕过。
提示：每次修改 manifest 或资源路径后，都要在 chrome://extensions 页面点击扩展的刷新按钮，然后重新打开原型页面，否则加载的还是旧缓存。
3.3 本地加载调试与打包 crx 的两种分发方式
本地调试阶段，直接用「加载已解压的扩展程序」最方便，改完代码点刷新就行。调试时打开原型页面，按 F12 打开开发者工具，Console 里看报错，Network 里看资源加载情况。如果某个资源 404，检查路径大小写，Chrome 扩展在部分系统上对大小写敏感。如果页面白屏，先看 Console 有没有 JS 报错，再看 index.html 的 body 里有没有内容。
调试通过后，如果要分发给别人，有两种方式。一种是直接打包成 .crx 文件，在 chrome://extensions 页面点击「打包扩展程序」，选择扩展目录，生成 .crx 和 .pem 文件。.pem 是私钥，要保管好，后续更新版本要用同一个 .pem 签名。另一种是把整个文件夹压缩成 zip，让对方解压后通过开发者模式加载。这种方式适合内部使用，不需要签名，但对方需要开启开发者模式。
需要注意的是，Chrome 对 .crx 文件的安装有限制，非商店来源的 .crx 可能会被拦截，提示「无法从该网站添加应用、扩展程序和用户脚本」。解决办法是把 .crx 文件拖到 chrome://extensions 页面，或者用组策略配置。如果分发对象是普通用户，最稳妥的方式还是让他们用开发者模式加载 zip 解压后的文件夹，虽然多几步操作，但不会被拦截。
打包命令可以用 Chrome 自带的打包功能，也可以用命令行。命令行方式如下：
# 使用 Chrome 命令行打包扩展 # --pack-extension 指定扩展目录 # --pack-extension-key 指定私钥文件（首次打包可不加，会自动生成） google-chrome --pack-extension=/path/to/axure-extension --pack-extension-key=/path/to/axure-extension.pem这条命令会在扩展目录的同级生成 .crx 文件。参数说明：--pack-extension 后面跟扩展目录的绝对路径，--pack-extension-key 后面跟 .pem 文件的绝对路径。首次打包不加 key 参数，Chrome 会自动生成一个 .pem，后续更新必须用同一个 .pem，否则扩展 ID 会变，已安装的用户无法自动更新。
4. 固定背景滚动与响应式在插件环境里的排查
4.1 固定背景滚动失效的三种原因与修复
Axure 里设置固定背景滚动，导出后在插件里打开，常见的问题是背景不固定，跟着页面一起滚。原因通常有三种。第一种是 CSS 里 background-attachment: fixed 被其他样式覆盖了。Axure 生成的 CSS 里，固定背景是通过这个属性实现的，但如果父容器有 transform 或 filter 属性，fixed 会失效。检查方法是打开开发者工具，选中背景元素，看 Computed 面板里 background-attachment 的值，以及父级有没有 transform。
第二种是 Axure 的「固定背景」设置没有正确导出。在 Axure 里，固定背景需要在「页面样式」里设置，并且要勾选「固定背景」选项。如果只在画布上把图片设为背景但没有勾选固定，导出后就不会有 fixed 效果。回到 Axure 源文件确认这个设置，重新导出。
第三种是扩展页面的视口高度问题。Chrome 扩展打开的标签页，视口高度是浏览器窗口高度减去地址栏和书签栏。如果 Axure 原型里用了 100vh 作为背景高度，在扩展里可能和预期不一致。解决办法是把背景容器的高度改为 100%，并确保 html 和 body 的高度也是 100%。可以在扩展的 CSS 里追加覆盖样式：
/* 修复扩展环境下固定背景失效 */ html, body { height: 100%; margin: 0; padding: 0; } .fixed-bg { background-attachment: fixed; background-size: cover; background-position: center; height: 100%; }这段 CSS 的逻辑是：先把 html 和 body 的高度撑满，然后给固定背景元素设置 background-attachment: fixed。如果原页面有 transform 的父级，需要把 transform 去掉或改成 none。参数说明：background-size: cover 保证背景图铺满，background-position: center 让背景居中。如果原页面用的是具体像素值，可以按需调整。
4.2 响应式断点在扩展窗口下的表现差异
Axure 原型的响应式断点通常是按浏览器窗口宽度触发的。在扩展里打开时，窗口宽度和普通浏览器标签页一样，所以断点逻辑本身不会变。但有一个差异：扩展页面没有地址栏下方的书签栏，实际内容区域的高度会比普通标签页大一些。如果原型里有基于高度计算的布局，比如垂直居中，可能会偏移。
另一个差异是缩放。Chrome 扩展页面默认缩放是 100%，但如果用户在浏览器设置里改了默认缩放，扩展页面也会跟着变。这会导致 Axure 原型里的像素级布局出现偏差。解决办法是在扩展的 CSS 里强制设置 zoom 或 transform: scale，但这样会影响所有页面。更稳妥的方式是在原型里用相对单位，比如百分比和 flex，减少对固定像素的依赖。
如果原型里有媒体查询，比如 @media (max-width: 768px)，在扩展里调整窗口大小时会正常触发。测试方法是把 Chrome 窗口拖窄，看布局是否按预期变化。如果没变化，检查媒体查询的断点值和 Axure 里的设置是否一致。Axure 导出时，媒体查询会写在 CSS 里，可以直接搜索 @media 确认。
4.3 用开发者工具定位资源 404 与脚本报错
资源 404 是插件加载原型时最常见的问题。打开开发者工具的 Network 面板，刷新页面，看哪些请求是红色的。常见的 404 包括：字体文件路径不对、图片路径大小写不一致、JS 文件被 CSP 拦截。对于字体和图片，检查路径是否和实际文件位置匹配。对于 JS 被拦截，Console 里会有 CSP 报错，按前面说的方法处理。
脚本报错方面，Axure 运行时如果版本和导出文件不匹配，可能会报「AxureRuntime is not defined」。这种情况通常是因为 resources 文件夹里的 JS 文件没有正确加载。检查 index.html 里的 script 标签，确认 src 路径是相对路径，并且文件确实存在。如果用的是 Axure RP 9 或 10 导出的文件，运行时文件名可能不同，不要手动改名。
还有一个隐蔽的问题是缓存。Chrome 扩展会缓存资源，修改文件后如果没刷新扩展，加载的还是旧版本。排查时先在 chrome://extensions 页面点击刷新，然后按 Ctrl+Shift+R 强制刷新原型页面。如果还不行，在开发者工具的 Application 面板里，点击 Clear storage，清除缓存后再试。
注意：如果原型里用了 WebSocket 或 fetch 请求外部接口，Manifest V3 需要在 host_permissions 里声明对应的域名，否则请求会被拦截。纯静态原型不涉及这个问题，但如果有动态数据加载，要提前配置。
5. 避坑记录：Axure 转 Chrome 插件最常见的五个翻车点
5.1 现象：加载扩展后点击图标没反应
原因：background.js 没有正确注册，或者 manifest 里 action 配置缺失。Manifest V3 要求 background 里写 service_worker，而不是 scripts。如果写成了 V2 的格式，扩展加载时会报错，但图标可能还显示，点击没反应。
解决：检查 manifest.json 里 background 字段，确保是 "service_worker": "background.js"。然后在 chrome://extensions 页面点击「Service Worker」链接，看 Console 有没有报错。如果 service worker 没启动，点击图标就不会触发监听函数。另外确认 action 字段存在，Manifest V3 里不能再用 browser_action。
5.2 现象：原型页面白屏，Console 报 CSP 错误
原因：index.html 里引用了远程脚本或样式，被 Manifest V3 的 CSP 拦截。Axure 导出时如果用了外部字体或 CDN 库，就会触发这个问题。
解决：搜索 index.html 和 CSS 文件里的 http:// 和 https://，把所有外部引用下载到本地，改成相对路径。如果用的是 Google Fonts，下载字体文件后改写 @font-face 的 src。改完后刷新扩展，重新打开页面。如果还有报错，看具体是哪个 URL 被拦截，逐个处理。
5.3 现象：固定背景滚动时抖动或闪烁
原因：background-attachment: fixed 在 Chrome 里对重绘性能有要求，如果背景图太大或页面有其他动画，会触发频繁重绘，导致抖动。另外，如果父容器有 transform，fixed 会退化成 scroll。
解决：压缩背景图体积，用 WebP 格式替代 PNG。检查父级元素，去掉不必要的 transform。如果抖动依然存在，可以改用 position: fixed 的伪元素来实现背景固定，而不是用 background-attachment。具体做法是创建一个 position: fixed 的 div，z-index 设为 -1，把背景图放在这个 div 上。
5.4 现象：打包 crx 后安装提示「无法从该网站添加」
原因：Chrome 对非商店来源的 crx 文件有安装限制，直接双击 crx 文件会被拦截。这是 Chrome 的安全策略，不是扩展本身的问题。
解决：把 crx 文件拖到 chrome://extensions 页面安装，或者让对方用开发者模式加载解压后的文件夹。如果必须用 crx 分发，可以配置组策略，在 ExtensionInstallAllowlist 里添加扩展 ID。对于内部使用，最省事的方式还是发 zip 压缩包，让对方解压后加载。
5.5 现象：更新扩展后，已安装用户没有收到新版本
原因：打包新版本时用了不同的 .pem 文件，导致扩展 ID 变化。Chrome 根据 .pem 文件生成扩展 ID，ID 变了就视为新扩展，不会覆盖旧版本。
解决：第一次打包时生成的 .pem 文件要妥善保管，后续所有版本都用同一个 .pem 签名。如果 .pem 丢了，只能让用户卸载旧版本，重新安装新版本。为了避免这个问题，我一般会把 .pem 文件和源码一起放在版本控制里，但要注意 .pem 是私钥，不要公开到公共仓库。
6. 进阶：给 Axure 插件加一个滚动位置记忆功能
前面讲的都是让原型能跑起来，这一章说一个进阶技巧：给插件加滚动位置记忆。演示时经常需要来回切换页面，如果每次打开都回到顶部，很影响体验。加一个记忆功能，关闭标签页再打开时，自动恢复到上次滚动的位置。
实现思路是在原型页面里注入一段脚本，监听滚动事件，把 scrollTop 存到 chrome.storage.local 里。页面加载时读取存储的值，恢复滚动位置。因为 Manifest V3 的 CSP 限制，不能直接在 index.html 里写内联脚本，需要把脚本放在单独的 JS 文件里，通过 content script 或直接在页面里引用。
更简单的做法是在 background.js 里用 chrome.scripting.executeScript 注入。但需要先申请 scripting 权限和 host_permissions。下面是具体实现。
首先修改 manifest.json，加上 scripting 和 storage 权限：
{ "manifest_version": 3, "name": "Axure Prototype Viewer", "version": "1.1.0", "permissions": ["tabs", "scripting", "storage"], "host_permissions": ["<all_urls>"], "action": { "default_title": "打开原型" }, "background": { "service_worker": "background.js" } }然后新建一个 scroll-memory.js，作为 content script 注入：
// 滚动位置记忆脚本 // 监听页面滚动，防抖后保存位置 let saveTimer = null; function saveScrollPosition() { // 用页面路径作为 key，区分不同页面 const key = 'scroll_' + window.location.pathname; const position = window.scrollY || document.documentElement.scrollTop; chrome.storage.local.set({ [key]: position }); } window.addEventListener('scroll', () => { // 防抖 300ms，避免频繁写入 clearTimeout(saveTimer); saveTimer = setTimeout(saveScrollPosition, 300); }); // 页面加载完成后恢复滚动位置 window.addEventListener('load', () => { const key = 'scroll_' + window.location.pathname; chrome.storage.local.get(key, (result) => { const position = result[key]; if (position && position > 0) { // 延迟执行，等页面渲染完成 setTimeout(() => { window.scrollTo({ top: position, behavior: 'instant' }); }, 100); } }); });这段代码的逻辑是：用 window.location.pathname 作为 key，把每个页面的滚动位置分开存储。滚动时防抖 300ms 再写入 chrome.storage.local，避免频繁 IO。页面 load 事件触发后，读取存储的位置，延迟 100ms 执行 scrollTo，等页面渲染稳定。参数说明：防抖时间 300ms 可以根据页面复杂度调整，如果页面很长、滚动很频繁，可以加到 500ms。延迟 100ms 是为了等 Axure 的动态面板渲染完成，如果恢复位置不准，可以加大到 200ms。
在 background.js 里注册 content script：
// 扩展安装或更新时注册 content script chrome.runtime.onInstalled.addListener(() => { chrome.scripting.registerContentScripts([ { id: 'scroll-memory', matches: ['<all_urls>'], js: ['scroll-memory.js'], runAt: 'document_idle' } ]); }); // 点击图标打开原型 chrome.action.onClicked.addListener(() => { chrome.tabs.create({ url: chrome.runtime.getURL('index.html') }); });这里用 chrome.scripting.registerContentScripts 动态注册，而不是在 manifest 里静态声明。好处是可以在扩展更新时重新注册，避免旧脚本残留。matches 设为 <all_urls> 是为了覆盖扩展页面，runAt 设为 document_idle 保证 DOM 加载完成后再执行。
验证方法是：打开原型，滚动到中间位置，关闭标签页，重新点击扩展图标打开，看是否恢复到上次位置。如果没恢复，打开开发者工具的 Console，看有没有报错。常见问题是 chrome.storage 权限没加，或者 content script 没有注入到扩展页面。可以在 chrome://extensions 页面点击「Service Worker」链接，在 Console 里输入 chrome.scripting.getRegisteredContentScripts() 查看注册状态。
这个功能的价值在于演示场景。给客户演示时，经常需要停在某个位置讲解，下次打开还能回到那里，省去重新滚动的麻烦。我自己的习惯是，任何需要反复演示的原型，都会加上这个记忆功能，成本很低，但体验提升明显。另一个类似的技巧是记住上次打开的页面，用 chrome.storage 存当前 URL，下次直接打开那个页面而不是 index.html。这两个功能加起来，基本就是一个顺手的原型查看器了。
希望帮到你。
本文还有配套的精品资源，点击获取
