简介：面向原型设计与产品协作场景的 Axure RP CRX 0.6.3 Chrome 插件包，适合使用 Axure RP 的设计师、产品经理及需要远程评审原型的团队成员。它将相关能力接入谷歌浏览器，便于在不频繁切换应用的情况下查看、测试与分享原型，降低安装配置门槛。压缩包共 11 个文件，约 129KB，包含 6 个 png 界面/步骤截图、2 个 js 脚本、1 个 html 页面、1 个 json 配置及 1 个 txt 使用说明，覆盖安装指引、扩展配置与操作提示。已有 2125 人学习下载。读者可依据截图和说明完成插件加载，结合扩展脚本与配置理解 Chrome 端运行方式，并用于原型预览、团队协作和远程演示，快速排查安装中的常见问题。

1. 从「拖进去没反应」说起：0.6.3 这个 CRX 究竟装进什么环境

把 Axure RP 导出的原型交给同事，对方双击 HTML 打开，页面一片空白，控制台飘红——这类现场我一年要接十几次。问题出在 Chrome 对 file:// 协议的处理上：原型页面要读 resources 目录里的脚本和数据，浏览器认为跨目录读取不安全，直接拦掉。官方提供的解决办法是一个浏览器扩展，即 Axure_RP_CRX_0.6.3_for Chrome 这个包，圈子里常说的 Axure.CRX 就是它。真正装的时候才发现，难点在 Chrome 这几年对非商店来源的 CRX 越来越严格：文件拖进扩展页毫无反应、弹一句 CRX_REQUIRED_PROOF_MISSING，才是常态，装成功反而少见。这篇记录写给两类人：一是要在自己机器上看原型的设计、产品、测试；二是要替整个小组把环境统一装好的运维。凡是靠双击 HTML 就能看原型的人，这套流程最好提前了解，可以省掉不少来回支持的麻烦。

2. 装前清点：Chrome 版本、CRX 包与原型目录三件套

动手前先把这三样东西摆到桌面上。装这套环境出问题的人，十有八九是软件本身没装错，而是文件层级、路径或浏览器版本先在某个环节出了偏差；到了安装那一步才排查，成本就高得多。这一章把环境清点一遍，后面两步会省很多返工。

2.1 三样东西缺一不可，先对一遍清单

这套组合一共三件东西，谁缺了都跑不起来：

最容易漏的是第三样。我见过太多次：对方发来一个压缩包，解压出来又套了一层同名文件夹，resources埋在第二层，入口 html 却在第一层，于是页面能打开、样式全丢、交互全废。判断方法很简单——入口 html 所在目录里，必须能直接看到resources。如果看不到，就往上一层或下一层找，直到两者平级为止。

第二样也常出错。rar 里装的可能是一个 crx，也可能里面还套了一层文件夹。不同解压工具对 rar 的处理不一样，有的会解出Axure_RP_CRX_0.6.3_for Chrome(谷歌浏览器插件)/这样的目录，有的会直接扔出 crx 文件。拿到手先ls看一眼，确认里面到底有几个文件，再决定下一步。

第三样是浏览器。0.6.3 这个扩展包本身比较老，manifest 大概率是 v2 年代的东西。新版 Chrome 对老扩展的处理方式是「已加载的继续用，但不再保证所有能力都完整」；更现实的问题在于，新版 Chrome 对从商店外安装的 CRX 限制更严。因此第一件要确认的事是：你的 Chrome 是不是最新稳定版。如果版本很新，装法就要走开发者模式那条路，不要指望拖拽。

2.2 先判断原型到底需不需要这个扩展

这一点很关键：并非所有 Axure RP 导出的原型都需要装扩展。有些原型在导出时已经产出了不依赖 XHR 读取的静态结构，或者干脆是通过本地服务访问的，装扩展纯属多余。花两分钟确认，能省掉后面一堆无效排查。

判断方法：直接打开入口 html，按 F12 看 Console。如果出现类似Access to XMLHttpRequest at 'file:///.../resources/...' from origin 'null' has been blocked by CORS policy的报错，或者页面结构出来了但交互点击无反应、动态面板全部塌陷，那就确实需要扩展。反过来，如果 Console 干净、交互正常，说明你拿到的是一份不依赖这种方式就能用的产物，无需再装。

第二种判断方法是从源头看，用 grep 查一下入口 html 引用了哪些资源：

# 看入口 html 顶层引用了哪些脚本，重点确认 resources 是不是相对路径 grep -o 'src="[^"]*"' start.html | head -20

这段命令把入口 html 里所有src属性抓出来，只看前 20 条。关注两点：路径是不是以resources/开头（相对路径，正常），有没有出现file:///绝对路径或者某个服务器地址开头（异常，换机器就废）。如果抓到的是/resources/xxx.js这种以斜杠开头的写法，说明它是从站点根目录视角写的，本地 file:// 打开一定会 404，这种情况装扩展也没用，得改用本地 http 服务，第四章会讲。

提示：Windows 上没有grep的话，用 PowerShell 的Select-String -Path start.html -Pattern 'src="'，思路一致。

2.3 解 rar、剥 CRX 头：两步都是机械操作

拿到 rar 之后，先解压。这一步别在压缩软件的预览窗口里直接双击 crx，双击大概率会被系统关联到浏览器，然后弹一句「无法添加」。

# 解 rar，输出到独立目录，避免和后续中间产物混在一起 mkdir -p ./axure_work/raw 7z x "Axure_RP_CRX_0.6.3_for Chrome(谷歌浏览器插件).rar" -o./axure_work/raw

7z x是完整解压并保留目录结构，-o指定输出目录（注意-o和路径之间没有空格，这是 7z 的规矩）。macOS 上用unrar x 文件名 目标目录/效果一样，没装的话brew install unrar补一个。文件名里有空格和括号，引号一定要加，不加会被 shell 拆成好几个参数，报「找不到文件」。

解出来以后确认一下：

ls -la ./axure_work/raw file ./axure_work/raw/*.crx

file命令应该回Chrome extension或者Zip archive data之类。如果回的是RAR archive，说明 rar 里还套了一层，继续解。

接下来是本次安装最关键的一步：把 CRX 的头部剥掉，还原成标准 zip。CRX3 格式不是普通压缩包，它开头有一段二进制头（魔数Cr24、版本号、头部长度、签名信息），直接改后缀成.zip有些工具能吃、有些直接报错。用 Python 精确取偏移最稳妥：

import struct, sys src = sys.argv[1] dst = sys.argv[2] with open(src, 'rb') as f: magic = f.read(4) if magic != b'Cr24': sys.exit('不是 CRX 文件，检查后缀和文件头') version = struct.unpack('<I', f.read(4))[0] if version == 3: # CRX3：4字节魔数 + 4字节版本 + 4字节头长度 + 头部 header_len = struct.unpack('<I', f.read(4))[0] offset = 12 + header_len elif version == 2: # CRX2：魔数 + 版本 + 4字节公钥长度 + 4字节签名长度 + 公钥 + 签名 pub_len, sig_len = struct.unpack('<II', f.read(8)) offset = 16 + pub_len + sig_len else: sys.exit(f'不认识的 CRX 版本：{version}') with open(src, 'rb') as f: f.seek(offset) payload = f.read() with open(dst, 'wb') as f: f.write(payload) print(f'版本 {version}，正文偏移 {offset}，已写出 {len(payload)} 字节')

参数就两个：第一个是 crx 路径，第二个是想要的 zip 输出路径。核心逻辑是读出头部长度，算出正文起点，把从起点到文件末尾的全部字节写出去——CRX 的正文就是标准 zip，一点没改。跑完会打出偏移量，这个数字记一下，日后同样的包再处理可以直接核对。

然后正常解压这个 zip，得到一个目录，目录里应该有manifest.json、_locales/、若干 js。看到manifest.json就说明拆对了。

unzip -o ./axure_work/axure.crx.zip -d ./axure_work/Axure_RP_CRX_0.6.3 python3 -m json.tool ./axure_work/Axure_RP_CRX_0.6.3/manifest.json | head -30

unzip -o是覆盖不询问，-d指定解压目录。第二行把 manifest 格式化后看前 30 行，重点看三个字段：manifest_version（判断新旧）、version（确认是不是 0.6.3）、content_scripts里的matches（判断它作用在哪些页面上）。有些版本还有permissions里带file:///*，那是它能读本地文件的前提。

到这一步，安装物料就齐了。剩下的就是把它装进浏览器。

3. 安装 Axure RP CRX 0.6.3：拖拽失败后的两条路

安装这一段我踩过的坑最多，也最容易被网上的旧教程带偏。很多教程还停留在「把 crx 拖进扩展页」的年代，照做的话十次有八次是静默失败——页面刷新一下，什么都没多出来，也不报错，让人怀疑是不是鼠标坏了。这一章把两条真正能走通的路写清楚。

3.1 拖拽安装为什么十次八次失败

Chrome 很早以前就收紧了策略：从商店之外安装的 CRX，必须带有来自商店的签名证明。你自己手上的 0.6.3 包是打包出来直接给人用的，没有这层证明，于是浏览器只做一件事——拒绝安装。表现形态有几种，值得记住，因为它们直接决定你下一步该干嘛：

表格里前三行是绝大多数情况。有个反直觉的点：拖拽失败不会在chrome://extensions里留下任何痕迹，也没有日志可查，这就是它被称为「黑匣子」的原因。所以我现在基本不推荐拖拽这条路，多试几次只会浪费时间。直接进开发者模式，一步到位。

3.2 开发者模式加载已解压目录：主线装法

这是目前最稳的装法，本质是让 Chrome 直接读你解压出来的目录，绕过整包签名校验。步骤固定，照着走：

1. 地址栏输入chrome://extensions回车，进入扩展管理页。
2. 右上角找到「开发者模式」开关，打开。打开后页面顶部会多出一排按钮。
3. 点左上角「加载已解压的扩展程序」。
4. 在弹出的目录选择框里，选中 2.3 解出来的那个目录——注意是包含 manifest.json 的那一层，不是它的父目录。
5. 确认后，列表里应该出现一个新条目，名字类似Axure RP Extension for Chrome，版本号 0.6.3。
6. 检查这个条目没有红色的「错误」按钮，有的话点开看详情。
7. 点「详情」，往下找到「允许访问文件网址」，把它打开。

第 4 步是新手翻车最多的地方。很多人选到了Axure_RP_CRX_0.6.3的上一层，Chrome 会报「清单文件缺失或不可读取」。判断标准很简单：你选中的那个目录，进去第一眼就能看到manifest.json。

第 7 步同样不能漏，它默认是关的。这个开关的含义是「允许此扩展在 file:// 页面上运行」，不打开的话扩展装是装上了，但打开本地原型页面时它根本不介入，你会以为是扩展坏了。开关的底层对应 manifest 里的文件访问权限声明，但 Chrome 把它单独拎出来做用户级授权，是出于安全考虑——安装扩展不等于允许它翻你硬盘。

装完之后，扩展默认没有图标显示在地址栏旁边，别慌，这是正常的。它是内容脚本型扩展，没有 popup 界面，不会给你一个可点的按钮。判断它活着没活着，要看它在页面上干了什么，而不是看它在工具栏上长得什么样。

3.3 用独立 profile 做隔离验证

如果这台机器上装了一堆扩展，排查时你永远分不清是谁在捣乱。我习惯用命令行起一个全新的临时配置目录，只加载这一个扩展，环境像白纸一样干净，出问题一眼就能定位。

# macOS：用 /tmp 下的独立配置目录起一个干净 Chrome "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" \ --user-data-dir=/tmp/axure-test-profile \ --no-first-run \ --no-default-browser-check

# Windows：命令行里执行，注意 chrome.exe 的完整路径 "C:\Program Files\Google\Chrome\Application\chrome.exe" ^ --user-data-dir="D:\tmp\axure-test-profile" ^ --no-first-run

--user-data-dir是三条里最关键的一个参数，它把书签、历史、扩展、缓存全部重定向到指定目录，相当于给你一个全新的浏览器，和日常用的那个完全隔离。--no-first-run跳过首次启动引导，--no-default-browser-check跳过默认浏览器检查。这两个纯粹是为了少点几下。

起来之后你会发现扩展是空的，需要在这个干净环境里按 3.2 的步骤重新加载一次目录。加载完，把原型 html 拖进这个新窗口打开，如果一切正常，说明问题不在浏览器全局环境，而在你日常那个 profile 上——多半是别的扩展抢了 file:// 的执行权，或者策略限制。这个对照实验的价值就在于此：把变量降到只剩一个。

还有一条命令要提醒：--load-extension=路径这种写法在较新的 Chrome 上已经不太可靠，有的版本直接忽略，有的版本报参数无效。所以它只能用来做临时对照，不要写成长期方案，更不要写进开机脚本里——哪天 Chrome 更新了，脚本悄无声息失效，你连日志都找不到。

4. 装完必须配的两处：文件访问开关与原型侧设置

装完不等于能用。这块是典型的「装完就以为结束」区域，实际上还有两处要动：浏览器侧的文件访问授权，和原型侧的路径规范。前者决定扩展能不能生效，后者决定页面能不能把资源加载全。

4.1 「允许访问文件网址」：不打开等于没装

回到chrome://extensions，找到刚装的 0.6.3，点进「详情」，往下滚，会看到一个「允许访问文件网址」的开关。默认是灰的、关的。打开它。

这个开关的行为逻辑值得说清楚。Chrome 把扩展的权限分成两类：一类是安装即生效的网络域权限，另一类是对本地文件的访问权限，后者必须用户显式点头。你把扩展装上了，只是给了它「存在」的权利；只有这个开关打开，它才有资格在你打开file:///...页面时介入处理。两者都满足，扩展才会真正作用在本地原型上。

打开之后，回列表页看一眼，扩展条目下方应该没有红色错误。如果有，点「错误」看堆栈，常见的是 manifest 里某条权限在新版 Chrome 上不被识别，这类报错多数只是警告，不影响核心功能，可以先放着。

一个实操上的小技巧：改完这个开关，最好把已经打开的原型页关掉重开，不要只按 F5 刷新。原因是内容脚本的注入是在页面导航时决定的，刷新有时走缓存路径，权限变更不一定会重新应用。我以前就被这个坑过半小时，反复刷新都无效，关掉重开立刻就正常了。

4.2 原型侧：入口文件与 resources 的相对路径

浏览器侧配好了，还得看原型自己争不争气。几个固定检查点：

入口 html 必须和resources目录同级。这是 Axure RP 导出时的默认结构，但在打包、解压、拷贝过程中经常被打乱。检查命令前面给过，这里补一个更直接的：

# 站在入口 html 所在目录，看 resources 是不是就在隔壁 ls -d ./resources && ls ./resources | head -5

能列出东西就说明结构对了。列不出来，就往上或往下一层找，找到后把整个目录结构调整成平级。

第二个检查点是路径写法。打开入口 html，搜一下有没有以/开头的资源引用：

grep -c 'src="/resources\|href="/resources' start.html

返回 0 是最理想的。返回非 0，说明有绝对路径，本地打开必然 404，因为/在 file:// 下指向的是文件系统根目录，不是你的原型目录。这种情况要么改成相对路径，要么走 4.3。

第三个检查点是文件名大小写。Windows 和 macOS 默认不区分大小写，Linux 区分。原型在一台机器上好好的，拷到另一台就白屏，很多时候就是Resources和resources对不上。这个坑很隐蔽，排查时优先看 Console 的 404 列表。

4.3 本地 http 服务：比装扩展更省事的一条退路

说个可能有点反直觉的话：如果原型只是要在几台机器上看，装扩展不一定是唯一选择，也不一定是最好选择。起一个本地 http 服务，用http://访问，同源策略就正常工作，扩展装不装都无所谓。

# 在原型根目录（入口 html 所在目录）起一个只监听本机的静态服务 python3 -m http.server 8080 --bind 127.0.0.1 --directory .

三个参数各有作用：8080是端口，被占用就换 8081；--bind 127.0.0.1限定只有本机能访问，别写成0.0.0.0，那等于对局域网开放；--directory .指定服务根目录，用点表示当前目录。跑起来后浏览器访问http://127.0.0.1:8080/start.html，入口文件名按你目录里实际的写。

两种方案怎么选，我一般按这个来判断：

这张表里最后一行是扩展方案的独特价值。有些内网机器策略很严，监听端口会被安全软件拦，那就只能老老实实装扩展。反过来，只要能开端口，http 方案在稳定性和可移植性上都更好——它不依赖任何扩展，换台机器把目录拷过去起个服务就行，没有「扩展 ID 变了」「权限没开」这些玄学问题。

5. 排查：扩展装上了却没用，五种需重点排查的情况

这一章按「现象 → 原因 → 解决」记录五个我真实处理过的现场。它们的共同点是：扩展确实装了，但页面表现就是不对。逐个对照着看，基本能覆盖九成以上的问题。

5.1 装不上：所有提示都指向「商店之外」

现象：开发者模式加载目录时，报「清单文件缺失或不可读取」；或者拖拽 crx 报CRX_REQUIRED_PROOF_MISSING；或者点了「加载已解压」但列表毫无变化。

原因：前一种是选错了目录层级，Chrome 找不到 manifest.json。后两种是 Chrome 对非商店来源 CRX 的策略限制，跟文件本身好坏没关系——同一个文件，换开发者模式加载目录就能成。

解决：先确认选中目录里第一眼能看到manifest.json，这是加载类报错的唯一判据。拖拽 way 直接放弃，按 3.2 走。如果开发者模式加载也报错，把报错原文完整看一遍：提到「无法加载清单」是目录问题，提到「权限」是 manifest 字段在新版上不被识别，后者多数可以先忽略，扩展仍能加载成功。

5.2 装上了但页面还是白屏

现象：扩展在列表里，开关是开的，打开原型 html，页面空白或者结构出来了但交互全无，Console 里一片红。

原因：按可能性排序依次是——「允许访问文件网址」没开；入口 html 和 resources 不在一层；路径用了绝对路径；扩展版本对不上原型生成版本，读不懂新的数据结构。

解决：第一步永远是回chrome://extensions看那个文件访问开关，这是最高频的原因，占我处理量的一半以上。第二步用 4.2 的三条命令核对目录结构和路径。第三步看 Console 具体报什么：报 404 是路径问题，报 CORS 是扩展没生效，报某个变量 undefined 大概率是版本不匹配。版本不匹配这个没法靠改配置解决，只能换一个和原型生成工具同代的扩展版本，或者改用本地 http 服务。

5.3 换台机器就不好使了

现象：A 机器上装好能用的一整套，拷到 B 机器，按同样步骤装完，打不开。

原因：最常见的两个——一是扩展 ID 变了。「加载已解压的扩展程序」的 ID 是根据目录路径推导出来的，路径一换，ID 跟着换，如果原型的某些逻辑里硬编码了旧 ID，就会断。二是原型目录本身在拷贝时被压缩工具改了结构，resources 埋进子目录。

解决：先核对目录结构，用 4.2 的命令过一遍，这一步能解决大半。如果确认结构没问题，那就是 ID 问题。稳妥的做法是不依赖固定 ID：把原型和扩展解压目录放在两台机器上完全一致的相对路径下（比如都放在~/axure_env/里），路径一致 ID 就一致。要彻底固定 ID，需要在 manifest 里补一个 key 字段，值由打包时的公私钥导出，这个操作对临时看原型来说投入产出比不高，我一般不做。

5.4 扩展详情页亮红字或自动停用

现象：加载成功，但当天用着好好的，第二天打开浏览器，扩展显示「已停用」，或者详情页里有红色「错误」按钮。

原因：新版 Chrome 对老版本 manifest（v2）的扩展在逐步收紧，某些能力被禁用后会触发自动停用。另一个原因是扩展自己抛了未捕获异常，Chrome 会把它标记为异常状态。

解决：先点「错误」看具体报什么，如果只是资源加载警告，点扩展卡片上的刷新按钮重新加载即可，功能通常还在。如果整条被停用、连开关都点不动，那说明这个版本在你的 Chrome 上已经跑不了了，别再折腾，直接切 4.3 的本地 http 服务方案。这也是我一直建议团队里同时准备 http 方案的原因——扩展这条路受浏览器策略影响太大，得有备选。

5.5 受管设备上根本进不了扩展页

现象：chrome://extensions能打开，但「开发者模式」开关是灰的，或者「加载已解压的扩展程序」按钮消失。

原因：这台机器加入了某种设备管理策略，扩展安装被集中管控，普通账号没有权限。

解决：这条路基本堵死了，不要想着绕过策略，那是另一码事。可行的做法是用 4.3 的本地 http 服务在127.0.0.1上跑，这个方案不碰扩展，不需要任何提权，多数策略环境下都能用。如果连本地端口都起不来，那就只剩最后一招——把原型放到内网已有的静态站点目录下，用现成的 http 地址访问，但这需要协调，不在自己能掌控的范围内。

注意：这五条里的处理顺序有讲究。先查权限开关，再查目录结构，最后才怀疑版本。反过来查的话，往往在版本上耗掉一小时，最后发现只是开关没开。

6. 验证跑通：三个动作确认扩展真在干活

装完、配完，最后一步是确认它真的在工作，而不是「看起来装了」。我固定做三个动作，两分钟出结论。

第一个动作是看扩展状态。进chrome://extensions，确认条目存在、开关是蓝的、没有红色错误、文件访问开关是开的。四项全过，浏览器侧就算过关。

第二个动作是在页面里看证据。打开原型入口 html，按 F12，Console 里敲一行：

// Axure 生成的原型会在页面上挂一个全局对象，能查到就说明脚本链通了 typeof $axure

返回"object"说明原型的核心脚本已经执行成功；返回"undefined"说明脚本没跑到，往上看 404 和 CORS 报错。这一步比看页面长得对不对可靠得多——页面可能因为缓存显示正常，但脚本其实没执行，点两下就露馅。

第三个动作是交互实测。别只看首页，找三个点试：一个页面跳转链接、一个动态面板切换、一个带状态的元件（比如标签页）。这三个各点一次，如果能正常响应，说明资源和数据都读到了；如果首页正常、点了没反应，问题在resources里的数据文件，回去查 Network 面板有没有 404。

把三个动作的期望结果整理成一张对照表，排查时直接对：

这套检查我吃过亏才固化下来。早几年装完就看一眼首页长得对不对，觉得对了就交差，结果同事拿去一点链接全废——首页是静态渲染的，压根没走脚本。从那以后我每次装完都强制走一遍这三个动作，尤其是交互实测那一步，不管多赶时间都不跳过。整套环境装下来，真正花时间的从来不是那几步点击，而是事后分不清「装好了」和「以为装好了」。希望这套流程能帮你少走一遍我走过的弯路。

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